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This  document  describes  facilities  within  ERIM's  C4PL  image 
processing  programming  language  that  allow  direct  manipulation  and 
generation  of  programming  code  for  the  Cyto-HSS  Neighborhood 
Processing  Stage.  The  Cyto-HSS  Stage  performs  complex  cellular 
(neighborhood)  and  point  transformations  on  eight-bit  images. 

C4PL  is  a  powerful,  general  purpose  language  for  constructing 
image  processing  algorithms  to  enhance  digital  images,  and  to  extract 
useful  data  from  digital  images.  Its  library  of  commands  that  provi  ie 
complex  image  transform  operations  with  single-line  commands  covers  a 
wide  range  of  useful  transforms.  8ut  it  is  nearly  impossible,  and  not 
even  desirable,  to  make  all  possible  operations  available  within  the 
Cyto-HSS  stage  accessible  to  the  programmer  as  single-line  commands. 

Since  all  feasible  operations  that  can  be  performed  by  the  stage 
cannot  be  produced  with  single  commands  within  C4PL,  methods  have  been 
provided  to  access  the  lowest  level  of  programming  of  the  stage. 
Algorithmists  who  need  to  transform  images  in  ways  not  directly 
supported  by  commands  in  C4PL  have  the  ability  to  set  up  their  own 
low-level  stage  program  data  blocks.  This  provides  the  knowledgeable 
C4PL  programmer  with  access  to  all  the  flexibility  inherent  in  the 
stage  hardware. 

Early  versions  of  the  C4PL  language,  and  its  predecessor  C3PL, 
did  not  have  the  commands  and  capabilities  necessary  to  directly 
program  the  stage  from  the  language  itself.  External  tasks  were 
devised  to  provide  this  access  to  the  lowest  levels  of  the  software 
system  to  allow  generation  of  user-defined  stage  code  blocks.  This 
method  of  programming  the  stage  is  still  available,  but  everything 
that  in  the  past  had  to  be  done  in  external  tasks  can  now  be  done  at 
the  C4PL  command  language  level. 

Stage  code  generation  is  an  art  that  deserves  to  be  hidden  from 
the  user--this  is  one  of  the  reasons  for  the  existance  of  C4PL.  The 
Cyto-HSS  Stage,  like  any  other  piece  of  specialized  p.ogrammable 
digital  hardware,  is  a  relatively  complicated  unit  that  requires 
detailed  knowledge  of  its  interal  structure  and  operational 
characteristics  to  program  effectively.  However,  the  complicated 
nature  of  the  beast  is  the  source  of  its  power;  in  the  hands  of 
knowledgeable  and  creative  programmers  it  can  be  made  to  perform 
wonderful  deeds  on  digital  data.  This  document  is  intended  to  provide 
the  necessary  knowledge. 
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1.1  REFERENCES 


Several  related  documents  and  textbooks  should  be  available  for 
the  stage  programmer's  reference. 

The  Stage  Programmer' s  Manual  provides  a  hardware-level 
description  of  the  stage's  internal  operation.  It  also  defines  the 
organization  and  contents  of  the  stage  code  program  data  block.  (This 
is  essential  for  C4PL  programmers  setting  up  their  own  stage  code 
blocks.) 

The  C4PL  Advanced  Programming  Manual  provides  much  detailed 
information  on  writing  external  tasks  in  C4PL.  External  tasks  (among 
other  things)  were  provided  in  C4PL  to  create  user-defined  stage  code 
blocks.  As  C4PL  has  evolved,  however,  the  capabilities  needed  to 
create  user-defined  stage  code  have  been  developed  within  C4PL  to  the 
point  where  external  tasks  are  no  longer  needed  for  this  purpose. 
Useful  information  is  contained  in  Chapters  3  (External  Tasks  in  C),  4 
(Operation  and  Programming  the  Cyto-HSS  Stage),  and  6  (Writing 
External  Tasks  in  Pascal). 

An  introduction  to  C4PL  and  descriptions  of  basic  capabilities 
and  functions  are  contained  in  the  C4PL  User's  Manual .  From  a 
stage  code  block  development  viewpoint,  the  interesting  portions  of 
the  User's  Manual  are  sections  4.2  through  4.4  (variables,  constants, 
and  expressions  and  operators).  Understanding  and  knowledge  of 
Chapter  5  material  on  C4PL  procedures  is  essential  for  development  of 
procedures  to  generate  stage  code  blocks.  Also,  Chapter  11  is  useful, 
as  it  describes  saving  stagecode  and  executing  stagecode. 

A  number  of  textbooks  exist  that  provide  background  information 
on  relevant  image  processing  and  computer  architecture  concepts.  For 
background  information  and  examples  of  the  concepts  of  cellular 
transformations  see  Cellular  Automata  by  E.F.  Codd.  Further 
illustrations  of  cellular  automata  concepts  may  be  found  in  Modern 
Cellular  Automata  by  K.  Preston  and  M.J.B.  Duff.  The  theoretical 
foundations  of  mathematical  morphology  and  its  applications  to  image 
analysis  are  described  in  Image  Analysis  and  Mathematical  Morphology 
by  J.  Serra. 
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2.0  CYTO-HSS  CONCEPTS 

The  Cyto-HSS  Stage  transforms  pixels  of  an  image  in  a 
programmably-def i ned  way.  An  image  is  presented  pixel-by-pixel  to 
each  stage  in  raster  scan  order  from  the  first  line  through  the  last 
line.  The  stage  transforms  each  pixel  by  evaluating  the  programmed 
transform  of  the  3  by  3  neighborhood  of  pixels  around  and  including 
the  input  pixel.  The  stage  retains  the  original  pixel  values  for  the 
two  most  recent  lines  of  an  image  as  it  passes  through,  in  order  to 
have  the  data  available  for  the  3  by  3  neighborhoods. 

The  "pipeline"  in  the  Cyto-HSS  is  a  serially-linked  set  of 
Cyto-HSS  stages.  Images  passed  through  the  pipeline  will  be 
transformed  in  a  programmably-defined  way  in  each  stage.  The 
resultant  image  output  of  each  stage  is  passed  to  the  input  of  the 
subsequent  stage.  In  this  way,  multiple  operations  on  an  image  can  be 
performed  in  one  "ci rcula^ion"  of  an  input  image  through  the  pipeline. 
The  Cyto-HSS' s  power  results  from  each  stage's  ability  to  produce  a 
neighborhood  transformed  image  pixel  in  one  "clock  tick"  of  the 
machine,  and  the  ability  to  cascade  stages  together  to  multiply  the 
number  of  neighborhood  transforms  that  occur  with  each  clock  tick. 

The  Cyto-HSS  has  as  its  primary  purpose  the  support  of  high-speed 
circulation  of  data  through  this  pipeline  of  stages  (and  other 
processing  modules) . 
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3.0  C4PL  IMAGE  PROCESSING  COMMANDS  THAT  PRODUCE  STAGECGDE 

C4PL  provides  dozens  of  commands  to  create  image  transformation 
operations.  All  of  these  commands  are  parameterized  to  the  fullest 
extent  possible  to  provide  the  maximum  flexibility  to  the  user  for 
specifying  the  desired  transformation. 

Before  proceeding  with  reading  the  detailed  explanations  of  the 
"inner  workings"  of  C4PL  stagecode  that  constitute  the  rest  of  this 
document,  an  overview  of  the  broad  range  of  predefined  image 
transformation  commands  available  in  C4PL  that  utilize  the  Cyto-HSS 
Stage  will  be  given.  This  material  is  a  large  subset  of  the 
introductory  material  in  the  EPICAL  Reference  Manual. 

Image  transformations  are  operations  which  perform  image 
processing  transformation  for  image  analysis  and  other  purposes. 

These  programs  make  up  the  EPICAL  Library  of  C4PL.  The  types  of 
transformations  available  in  EPICAL  include: 

Combining  Images 
Geometric  Transformations 
Global  Transformations 
Local  Transformations 
Point  Transformations 
Translation-8ased  Operations 

Local  Transformations  and  Point  Transformations  (which  encompass 
tne  large  majority  of  the  commands  defined  in  C4PL)  are  the  commands 
which  utilize  the  Cyto-HSS  stage.  These  families  of  commands  are 
briefly  outlined  below.  (For  detailed  information  on  any  command, 
reference  the  C4PL  EPICAL  Reference  Manual.) 


3.1  LOCAL  TRANSFORMATIONS  OVERVIEW 

Local  Transformations  are  image  processing  operations  that  use 
the  value  of  the  neighboring  pixels  to  determine  the  new  value  of  each 
pixel . 


The  types  of  local  transformations  of  the  EPICAL  Library  include: 

Cellular  Transformations 

Edge  Detection 

Filters 

Maxima/Minima 

Morphological 

Shading 
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3.1.1  Cellular  Transformations  Overview 


Cellular  Transforms  are  image  processing  operations  that  perform 
neighborhood  tranformations .  Cellular  transforms  in  tne  EPICAL 
Library  include: 


Ave4 

Ave5 

Ave8 

Ave9 

Aver 

Clampcen 

Convolve 

Countnei 

Countwin 

Findends 

Findtees 

Markends 

Marktees 

Match 

Peakdete 

Peelhex 


Shift 


Span 

Spandisk 

Spanduod 

Spanv 

Tran 


Calculates  the  average  of  a  subset  of  the 

3  by  3  window  (east,  west,  north  and  south), 
not  including  the  center 
Calculates  the  average  of  a  subset  of  the 

3  by  3  window  and  then  averages  this  value  with 
the  value  of  the  original  center 
Calculates  the  average  of  all  eight  neighbors, 
not  including  the  center 
Calculates  the  average  of  the  neighbors  of  the 
3  by  3  window  and  then  averages  this  value  with 
the  value  of  the  original  center 
Replaces  each  pixel  with  the  average  of  a 
specified  set  of  its  neighbors 
Donut  filter  primitive.  Eliminates 

discontinuities  in  the  image  by  chopping  off 
peaks  and  filling  in  negative-going  valleys 
Performs  a  convolution  using  a  3  by  3  kernel 
Changes  the  state  of  each  active  pixel  to  the 
total  of  its  active  neighbors,  not  including 
the  center 

Changes  the  state  of  each  active  pixel  to  the 
total  number  active  neighbors,  including 
the  center 

Finds  endpoints  of  lines  in  specified  state 
Finds  T-connections  in  a  rectangular  skeleton, 
assuming  4-way  connectivity 
Marks  endpoints  of  lines  in  specified  state 
Marks  T-connections  in  a  rectangular  skeleton, 
assuming  4-way  connectivity 
Transforms  all  pixels  whose  neighbors  match  the 
specified  pattern 

Detects  the  peaks  (i.e.,  local  maxima) 

Performs  a  series  of  hexagonal  2-D  erosions  on 
all  objects  in  a  specific  state,  modifying  the 
state  of  the  main  regions  and  leaving  the 
periphery  in  the  original  state 
Translates  an  image  by  a  specified  distance  in  the 
specified  compass  direction  (N,  NE.  E,  SE,  S, 
SW,  W  or  NW) . 

Conditionally  dilates  pixels  in  an  image 
Conditional  2-D  dilation  by  a  disk 
Conditional  2-0  dilation  by  a  duodecagon 
Conditionally  dilates  pixels  in  an  image  over 
selected  neighbors 

Conditionally  transforms  the  pixels  in  an  image 
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T  ranb 
T  ranbx 


Trans',  at 


T  ran  v 


See  also: 


Conditionally  transforms  the  pixels  in  an  image 
using  all  selected  neighbors 
Conditionally  transforms  the  pixels  in  an  image 
using  exactly  the  selected  neighbors 
Translates  the  active  image  X  pixels  to  the 
east,  and  Y  pixels  to  the  south 
Conditionally  transforms  the  pixels  in  an  image 
using  selected  neighbors 

Edge  detection/gradient  extraction,  filters, 
maxima/minima,  and  morphological  transforms 


3.1.2  Edge  Detection/Gradient  Extraction  Overview 

The  Edge  Detection/Gradient  Extraction  routines  preserve  and/or 
enhance  the  regions  of  the  image  with  local  discontinuities.  There 
are  a  very  large  number  of  techniques  of  this  type,  and  each  has 
different  characteristics  depending  on  the  nature  of  the  image,  the 
objects  of  interest,  and  any  noise  or  distortions  present.  Several 
different  routines  have  been  included  in  EPICAL,  and  more  are  being 
added  as  they  evolve. 

The  following  edge  detection/gradient  extraction  operations  are 
available  in  EPICAL: 


Oiffl 
Di  f  f  2 
Getedge4 


Getedges 

GradEW 

Gradient 


GradNESW 

GradNS 

GradNWSE 

Grad4 

SlopeEW 

SlopeNS 

Sobel 

Sobeldi r 


Takes  the  directional  first  difference  of  an 
image  in  the  specified  direction 
Takes  the  directional  second  difference  of  an 
image  in  the  specified  direction 
Maximum  of  the  local  maxima  of  directional 
gradients  in  the  north-south  and  east-west 
directions  only,  in  rectangular  coordinates 
Maximum  of  the  local  maxima  of  all  directional 
gradients  in  rectangular  coordinates 
Gradient  in  the  east-west  direction 
Maximum  of  all  directional  gradients  in 
rectangular  coordinates 
Gradient  in  the  northeast-southwest  direction 
Gradient  in  the  north-south  direction 
Gradient  in  the  northwest-southeast  direction 
Maximum  of  north-south  &  east-west  gradients 
Synonym  for  Difflxx 
Synonym  for  Di ff lyy 

Performs  a  Sobel  edge  detection  using  a  3  by  3 
neighborhood  on  a  rectangular  image 
Computes  the  Sobel  edge  direction  values 
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3.1.3  Filters 

Filters  are  used  to  remove  noise,  such  as  details  and  distortions 
in  the  image  outside  the  size  range  of  interest  which  can  cause 
difficulties  and  inaccuracies  in  processing  the  image.  The  filters 
listed  below  remove  both  light  and  dark  (foreground  and  background) 
noise.  To  remove  only  one  or  the  other  type  of  noise  use  an  opening 
or  a  closing.  Many  of  the  filters  are  iterative,  progressively 
operating  on  the  image  with  sequentially  larger  versions  of  the 
specified  structuring  element.  This  has  the  effect  of  removing  larger 
and  larger  noise  features. 

2- D/Binary  Filters 

2D  filters  take  a  binary  (or  multi-state)  image  as  input.  The 
specified  state  is  filtered,  and  the  pixels  which  are  changed  can  be 
put  into  another  specific  state.  These  filters  will  remove  small 
regions,  fill  in  small  holes  in  blobs,  and  smooth  the  outlines  of 
regions. 

These  filters  can  also  be  used  to  extract  the  small  details. 

After  filtering,  the  pixels  which  are  different  from  the  original 
image  can  be  extracted  (e.g.,  using  an  image  subtraction)  and  used  in 
subsequent  algorithm  steps. 

3- D/Greyscale  Filters 

These  filters  treat  the  image  data  as  a  continuous  sequence  of 
increasing  values.  They  treat  the  two-dimensional  array  of  eight-bit 
pixels  (the  image)  as  a  three-dimensional  surface,  with  the  value  of 
each  pixel  representing  the  height  of  the  surface  at  that  point.  In 
reality,  the  pixel  value  may  represent  intensity,  range,  color,  or  any 
other  type  of  data  value.  These  operations  perform  a  neighborhood 
transformation  over  a  three-dimensional  neighborhood  in  rectangular 
coordinates.  There  is  currently  no  software  support  for  a 
three-dimensional  hexagonal  (footprint)  neighborhood. 

3-D/greyscale  filters  can  be  used  for  background  normalization. 
Background  normalization  refers  to  a  method  of  solving  a  common 
problem  with  grey-level  images.  The  problem  occurs  when  objects  of 
differing  depths/brightnesses  need  to  be  recognized  on  a  varying 
background.  Simple  thresholding  would  not  work  because  different 
objects  may  not  have  the  same  threshold,  and  the  background  itself  may 
contain  values  above  the  threshold.  The  basic  idea  is  to  remove  the 
objects  from  the  background.  This  resultant  image  is  then  subtracted 
from  the  original  image,  causing  the  background  to  be  removed.  The 
objects  are  then  readily  discernable  from  the  new  background. 

The  following  2D/binary  filters  are  available  in  EPICAL: 

DiskFil  Disk  filter-synonym  for  IsoFi 12D 
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Hullfil  Performs  an  iterative  filtering  of  an  image  by 
successively  taking  the  convex  hull  of  the 
foreground  and  background 
I soF i 1 2D  20  Iterative  isotropic  filter 


The  following  30/greyscale  filters  are  available  in  EPICAL: 


ArchFi EW 

ArchFi NS 

AutoMedian 
ClampCen 
ConeFi 1 
ConeTipF 

CubeFi 1* 
CylFi 1* 
OonutFil* 

DonutIFi* 

Fi lterby 

Gaussian 

HoleFi 1* 
IsoFi 130 
Median 

PyramidF 
SphereFi* 
SpikeFi 1* 
WallFiEW* 

WallFiNS* 


Iterative  filter  using  an  arch  oriented  in  the 
east-west  direction 

Iterative  filter  using  an  arch  oriented  in  the 
north-south  direction 
Pseudo-median  filtering 
Clamp  center  (donut  filter  primitive) 

Iterative  filter  using  a  cone 
Iterative  filter  using  a  cone  with  the  origin 
at  the  tip 

Iterative  filter  using  a  cube 
Iterative  filter  using  an  upright  cylinder 
Iterative  filter  using  a  donut  (ring  shaped) 
structuring  element 

First  order  donut  filter  (seven  of  eight 
neighbors) 

Iterative  filter  with  specified  structuring 
element 

Convolves  image  with  Gaussian  kernel  of 
specified  size 

Remove  (fill  in)  holes  (isolated  dark  pixels) 
3-0  isotropic  filter-synonym  for  SphereFi 
Replaces  center  pixel  values  with  the  median 
of  the  neighborhood  values 
Iterative  filter  using  a  pyramid 
Iterative  filter  using  a  sphere 
Filter  (remove)  spikes  (isolated  bright  pixels) 
Iterative  filter  using  a  wall  oriented  in  the 
east-west  direction 

Iterative  filter  using  a  wall  oriented  in  the 
north-south  direction 


*Can  also  be  used  on  binary  images  (but  not  multi-state  images). 
See  also:  Openings,  Closings 


3.1.4  Maxima  And  Minima  Transformations  Overview 

The  following  Maxima  and  Minima  operations  are  available  in 
EPICAL: 

LMax  Local  Maximum--replaces  center  pixel  with  the 

maximum  of  the  specified  neighbors 
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LMin 

Max3D 

MaxEW 

MaxexO 

MaxNESW 

MaxNS 

MaxNWSE 

MaxovO 

Min3D 

MinEW 

MinexO 

MinNESW 

MinNS 

Min NWS E 

PeakDete 


Local  Minimum--replaces  center  pixel  with  the 
minimum  of  the  specified  neighbors 

Replaces  each  pixel  with  the  maximum  of  the 
neighbors  value 

Retains  only  those  pixels  which  are  a  maximum 

with  respect  to  their  neighbors  in  the  east-west 
di recti  on 

Replace  the  center  pixel  with  the  unbiased 

maximum  of  the  neighborhood  pixels  except,  when 
the  center  is  zero 

Retains  only  those  pixels  which  are  a  maximum 
with  respect  to  their  neighbors  in  the 
northeast-southwest  direction 

Retains  only  those  pixels  which  are  a  maximum 
with  respect  to  their  neighbors  in  the 
north-south  direction 

Retains  only  those  pixels  which  are  a  maximum 
with  respect  to  their  neighbors  in  the 
northwest-southeast  direction 

Replace  the  center  pixel  with  the  unbiased 

maximum  of  the  neighborhood  pixels,  only  if  the 
center  is  zero 

Replaces  each  pixel  with  the  minimum  of  the 
neighbors  values 

Retains  only  those  pixels  which  are  a  minimum 

with  respect  to  their  neighbors  in  the  east-west 
direction 

Replace  the  center  pixel  with  the  unbiased 

minimum  of  the  neighborhood  pixels,  except  when 
the  center  is  zero 

Retains  only  those  pixels  which  are  a  minimum 
with  respect  to  their  neighbors  in  the 
northeast-southwest  direction 

Retains  only  those  pixels  which  are  a  minimum 
with  respect  to  their  neighbors  in  the 
north-south  direction 

Retains  only  those  pixels  which  are  a  minimum 
with  respect  to  their  neighbors  in  the 
northwest-southeast  direction 

Retains  only  those  pixels  which  are  a  peak  with 
respect  to  their  neighbors 


3.1.5  Morphological  Transformations  Overview 

Morphological  Transformations  are  local  image  processing 
transformations  based  on  geometric  operations  for  image  enhancements 
and  shape  analysis.  The  types  of  morphological  transformations  in  the 
EPICAL  library  include: 

2-0/Binary  Transforms 
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3-D/Greyscale  Transforms 

Closings 

Convex  Hulls 

Conditional  Dilations 

Di lations 

Erosions 

Openings 

Skeletons 

Size  Encoding 

See  also:  Cellular  Transforms,  Filters,  Closings,  and  Openings 


3.1.5.L  Binary(2-D)  Transformations  Overview 

Two-dimensional  image-processing  commands  are  used  to  alter  a 
digital  image,  taking  into  account  the  values  of  pixels  which  are 
adjacent  to  each  other  in  the  image. 

SPAN  and  TRAN  commands. 

Span  and  Tran  are  the  oldest  2-D  image  processing  commands  and 
have  been  superseded  by  the  more  general  MATCH  command.  Though  these 
two  commands  take  the  same  parameters,  the  parameters  have  different 
names  reflecting  the  conceptual  difference  in  the  commands.  A  span 
(dilate)  command  conceptually  takes  pixels  in  the  source  state  and 
grows  outward  from  the  source  over  pixels  in  the  medium  state, 
changing  medium  state  pixels  to  the  resultant  wave  state.  The  tran 
(transform)  commands  conceptualize  the  transformation  the  other  way 
around:  if  the  pixel  in  the  specified  center  state  is  surrounded  by 
the  specified  configuration(s)  of  pixels  in  the  neighbor  state,  then 
the  center  pixel  is  changed  to  the  output  state.  (Note  than  any  span 
command  can  be  changed  to  a  corresponding  tran  command  by  specifying 
neighbor  *  source,  center  =  medium,  output  =  wave,  and  reflecting  the 
neighborhood  specification  (if  any)  across  the  center). 

HEXFLG  may  be  reset  whenever  a  SPAN  or  TRAN  command  is  given.  To 
set  it  to  true  (i.e.  use  the  hexagonal  mode),  append  an  H  to  the 
command  (SPANH,  TRANH) .  To  set  it  to  false,  (i.e.  use  the  rectangular 
mode),  append  an  R  to  the  command  (SPANR,  TRANR) . 

A  special  transformation  can  be  enabled  by  giving  a  parameter 
value  of  "ALL"  (meaning  over  any  center  or  medium).  The  center  or 
medium  is  transformed  to  the  output  state  whenever  the  transformation 
test  (neighbors  of  the  specified  value  in  the  specified  configuration) 
succeeds,  regardless  of  original  center  or  medium  value. 

See  also:  Cellular  Transformations. 
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3. 1.5.2  Greyscal e(3D)  Transformations  Overview 

A  group  of  commands  is  included  in  C4PL  which  process  image  data 
in  a  3-D  manner.  These  commands  treat  the  two-dimensional  array  of 
eight-bit  pixels  (the  image)  as  a  three-dimensional  surface,  with  the 
value  of  each  pixel  representing  the  height  of  the  surface  at  that 
point.  In  reality,  the  pixel  value  may  represent  intensity,  ranqe 
color,  or  any  other  type  of  data  value.  These  operations  perform  a 
neighborhood  transformation  over  a  three-dimensional  neighborhood  in 
rectangular  coordinates.  There  is  currently  no  software  support  for  a 
three-dimensional  hexagonal  (footprint)  neighborhood. 

See  also: 

Closings 

Dilations 

Erosions 

Filters 

Openings 


3. 1.5. 3  Closings  Overview 

A  Closing  is  a  dilation  followed  by  an  erosion  with  the  same 
structuring  element.  Closings  remove  isolated  dark  points, 
concavities  and  background  regions  smaller  than  the  structuring 

ar^avaiUMe-15  US6d‘  ^  fol1owin9  closings  by  structuring  elements 


ClArchEW 

ClArchNS 

CIConeTi 

CloseCon 

CloseCub 

CloseCyl 

CloseOis 

ClosePyr 

CloseSph 

ClWallEW 

ClWallNS 

Proper_Closing 


Closing  by  an  arch  oriented  in  the 
east-west  direction 
Closing  by  an  arch  oriented  in  the 
north-south  direction 
Closing  by  of  a  cone  with  the  origin  at 
the  tip 

Closing  by  a  cone 
Closing  by  a  cube 
Closing  by  an  upright  cylinder 
Closing  by  a  disk 
Closing  by  a  pyramid 
Closing  by  a  sphere 
Closing  by  a  wall  oriented  in  the 
east-west  direction 
Closing  by  a  wall  oriented  in  the 
north-south  direction 
Filtering  operation  to  remove  localized 
dark  features 


See  also:  Openings  and  Filters. 
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3. 1.5.4  Convex  Hulls  Overview 


A  convex  hull  is  the  smallest  convex  shape  which  contains  the 
figure.  This  is  roughly  equivalent  to  placing  a  rubber  band  around 
each  connected  region  of  foreground  pixels,  changing  the  pixels  which 
are  in  the  concavities  and  holes.  The  convex  hull  routines  in  EPICAL 
compute  approximations  limited  by  the  digital  grid  space.  Increasing 
the  number  of  sides  used  improves  the  accuracy,  but  increases  the 
execution  time.  The  following  convex  hull  transformations  are 
available  in  EPICAL  on  two-dimensional  (binary  or  multi-state)  images: 

Hu 1 1 12  Ouodecagonal  (twelve  sided)  hull 

(hexagonal  grid) 

Hull  16  Sixteen-sided  hull  (rectangular  grid) 

Hu  11 4  Rectangular  hull  (rectangular  grid) 

Hu  1 1 6  Hexagonal  hull  (hexagonal  grid) 

HullG  Octagonal  hull  (rectangular  grid) 


3. 1.5. 5  Conditional  Dilations  Overview 

The  following  Conditional  Dilations  are  available  in  the  EPICAL 
Library: 

Match 

Span 

SpanDisk 
SpanDuod 
Tran 


Transforms  all  pixels  whose  neighbors 
match  the  specified  pattern 
Conditionally  dilates  pixels  in  an  image 
Span  Disk  (Rectangular) 

Span  Duodecagonal  (Hexagonal) 
Conditionally  transforms  the  pixels  in 
an  image 


3. 1.5. 6  Dilations  Overview 


The  following  Dilations  by  3-D  structuring  elements  are  available 
in  the  EPICAL  Library: 


OArchEW 

DArchNS 

DCone 

DConeTip 

DCube* 

DCyl* 

Dilate 


Dilate  by  an  arch  oriented  in  the  east-west 
di recti  on 

Dilate  by  an  arch  oriented  in  the  north-south 
direction 
Dilate  by  a  cone 

Dilate  by  a  cone  with  the  origin  at  the  tip 
Dilate  by  a  cube 
Dilate  by  an  upright  cylinder 
Expands  an  image,  treating  it  as  a 
three-dimensional  surface 
Dilate  by  a  pyramid 
Dilate  by  a  sphere 

Dilate  by  a  wall  oriented  in  the  east-west 


DPyramid 
DSphere 
Owal 1 EW* 
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di recti  on 

DwallNS*  0 i late  by  a  wall  oriented  in  the  north-south 
di recti  on 

Lmax*  Replaces  the  center  pixel  with  the  maximum  of 

the  enabled  neighborhood  pixels 
Match  Transforms  all  pixels  whose  neighbors  match 

the  specified  pattern 

Span  Conditionally  dilates  pixels  in  an  image 

Spandisk  Conditional  2-D  dilation  by  a  disk 
Tran  Conditionally  transforms  the  pixels  in  an 

image 

2-D  Dilations  Dilations  on  2-D  binary/multistate  images 
♦Can  also  be  used  on  binary  (but  not  multistate)  images 


3. 1.5. 7  Erosions  Overview 


Erosions  by  the  following  3-D  structuring  elements  are  available 
for  use  in  the  EPICAL  library: 

EArchEW  Erode  by  an  arch  oriented  in  the  east-west 

direction 

EArchNS  Erode  by  an  arch  oriented  in  the 

north-south  direction 
ECone  Erode  by  a  cone 

EConeTip  Erode  by  a  cone  with  the  origin  at  the  tip 

ECube*  Erode  by  a  cube 

ECyl*  Erode  by  an  upright  cylinder 

EPyramid  Erode  by  a  pyramid 

Erode  Shrinks  an  image,  treating  it  as  a 

three-dimensional  surface 
ESphere  Erode  by  a  sphere 

EwallEW*  Erode  by  a  wall  oriented  in  the  east-west 

direction 

EwallNS*  Erode  by  a  wall  oriented  in  the  north-south 
di recti  on 

Lmin*  Replaces  the  center  pixel  with  the  minimum  of 

the  enabled  neighborhood  pixels 
Match  Transforms  all  pixels  whose  neighbors  match 

the  specified  pattern 

Span  Conditionally  dilates  pixels  in  an  image 

Spandisk  Conditional  2-D  dilation  by  a  disk 
Spanduod  Conditional;  2-D  dilation  by  a  duodecagon 
Tran  Conditionally  transforms  the  pixels  in  an 

image 

2D  Erosions  Erosions  on  2-D  binary/multistate  images 
♦Can  also  be  used  on  2-D  binary  (but  not  multistate)  images 
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3. 1.5. 8  Openings  Overview 


Opening  is  an  erosion  followed  by  a  dilation  with  the  same 
structuring  element.  Openings  remove  isolated  bright  points, 
convexities  and  foreground  regions  smaller  than  the  structuring 
element  which  is  used.  The  following  openings  by  structuring  elements 
are  available: 


OpArchEW 

OpArchNS 

OpConeTi 

OpenCone 

OpenCube* 

OpenCyl i* 

OpenDisk 

OpenPyra 

OpenSphe 

OpWallEW* 

OpWallNS* 

Proper_Opening 


Opening  by  an  arch  oriented  in  the 
east-west  direction 
Opening  by  an  arch  oriented  in  the 
north-south  direction 
Opening  by  a  cone  with  the  origin  at 
the  tip 

Opening  by  a  cone 

Opening  by  a  cube 

Opening  by  an  upright  cylinder 
Opening  by  a  disk  (2-0  images  only) 

Opening  by  a  pyramid 

Opening  by  a  sphere 

Opening  by  a  wall  oriented  in  the 

east-west  direction 
Opening  by  a  wall  oriented  in  the 
north-south  direction 
Filtering  operation  to  remove  localized 
bright  features 


*Can  also  be  used  on  2-0  binary  (but  not  multistate)  images 


3. 1.5. 9  Skeletons  Overview 

A  Skeleton  is  stick  figure  that  results  when  a  region  is  thinned 
with  a  connectivity  preserving  algorithm.  Mathematically  speaking,  it 
is  all  of  the  pixels  which  are  equidistant  from  two  or  more  background 
pixels.  The  skeletonizing  routines  in  EPICAL  remove  pixels  on  the 
perimeter  of  the  foreground  regions  if  they  are  not  on  the  skeleton. 
These  routines  work  from  only  one  direction  on  each  step,  proceeding 
sequentially  around  the  regions  so  that  thin  lines  will  not  be  broken. 
Skeleton  procedures  available  in  EPICAL  are: 

SkelHex  Produces  a  skeleton  with  hex 

connectivity  (hexagonal  grid) 

SkelRec4  Produces  a  skeleton  with  N, 

S,  E,  and  W  connectivity  (rectangular 

grid) 

SkelRec8  Produces  a  skeleton  with  eight 

neighbor  connectivity  (rectangular  grid) 

In  addition,  the  following  routines  are  available  which 
thin  the  foreground  regions  from  only  a  single  direction: 
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ReduceE 

ReduceN 

Reduces 

ReduceW 


Reduce  from  the  east  side 
Reduce  from  the  north  side 
Reduce  from  the  south  side 
Reduce  from  the  west  side 


3.1.5.10  Size  Encoding  Overview 

Size  Encoding  is  the  labeling  of  each  foreground  pixel  with  a 
value  representing  its  distance  to  the  nearest  background  regions. 
Functions  of  this  class  are  called  distance  transforms.  The  following 
size  encoding  routines  are  available  in  EPICAL: 

SizeEncdR  Size  encoded  erosion  of  an  image  by  a  45-degree 

cone  (pyramid)  whose  origin  is  at  its  tip 
(rectangular  grid) 

PeelHex  Performs  a  series  of  hexagonal  2-D  erosions  on 

all  objects  in  a  specified  state,  modifying  the 
state  of  the  main  regions  and  leaving  the 
periphery  in  the  original  state  on  each  pass 


3.1.6  Shading  Overview 

Shading  operations  treat  a  grey-scale  image  as  a 
three-dimensional  surface  and  selectively  lighten  or  darken  the  image 
to  provide  the  appearance  of  depth  due  to  directional  illumination. 
The  following  shadings  are  available  in  EPICAL: 

Shade  Shade  a  grey-scale  image  as  if  there  were  a 

light  source  in  the  upper  right  hand  corner 
of  the  screen 

Shadow  Shadow  a  grey-scale  image  as  if  there  were  a 

light  source  in  the  upper  right  hand  corner  of 
the  screen,  given  the  length  of  the  shadow 
to  cast 


See  also:  Plot3D 


3.2  POINT  TRANSFORMATIONS  OVERVIEW 

Point  Transformations  are  operations  that  take  in  one  image  and 
modify  the  pixel  values  based  only  on  the  values  themselves;  that  is 
they  ignore  the  neighborhood  of  pixels  around  them. 

The  pixel  transformations  performed  by  the  commands  in  this 
category  are  actually  carried  out  in  the  hardware  of  the  Cyto-HSS.  In 
each  stage  a  256  by  8  lookup  table--the  PRAM  (Point-transform  Random 
Access  Memory)--is  used.  This  table  is  loaded  with  the  desired  pixel 
values,  and  the  original  value  serves  as  an  index  into  this  table. 
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When  no  transformation  is  desired,  the  table  is  bypassed.  This  means 
that  these  operations  are  carried  out  quickly  and,  in  fact,  take  no 
additional  time  when  done  in  concert  with  other  operations  performed 
by  the  stages.  Any  transformation  is  possible,  and  a  number  of  useful 
ones  have  been  included  in  EPICAL.  The  EPICAL  commands  that  perform 
point  transformations  are  briefly  described  below. 


Abs 

BitAnd 

Bi tClear 

BitCl r 

BitCopy 

BitNot 

BitOr 

BitRot 

BitSet 

BitSwap 

BitXor 

Cover 

Exch 

Exp 

Log2 

LogE 

OnesComp 

Prune 

Quant 

Remove 

Scale 

ScaleRem 

SetDR 


Slice 

SQRT 

SQR 

Threshol 

TwosComp 


Takes  the  absolute  value  (i.e.,  values  128  to 
255  are  mapped  into  values  of  127  to  1) 

Logical  ANDs  between  two  bit  planes 
Sets  the  bit  plane  to  zero 
Synonym  for  Bi tclear 
Copies  a  bit  plane 
Logical  complement  of  a  bit  plane 
Logical  OR  between  two  bit  planes 
Rotation  (barrel  shift)  of  the  bits  of  each 
pixel 

Sets  a  bit  plane  to  one 

Exchanges  two  bit  planes 

Logical  exclusive-OR  between  two  bit  planes 

Covers  one  pixel  value  with  another 

Exchanges  two  pixel  values 

Exponential  function 

Function  returning  log  base  2  of  an  argument 
Natural  logarithm  function 
Ones  complement  of  an  image 
Changes  pixel  values  within  a  given  range 
Sets  the  pixels  in  a  given  range  (or  ranges)  to 
a  single  value  (or  values) 

Sets  all  values  within  a  specified  range  to  zero 
Scales  the  pixels  by  multiplying,  dividing  or 
adding  constants  to  the  values 
Produces  a  remainder  image  consistent  with  SCALE 
Sets  the  dynamic  range  of  an  image  by  rescaling 
pixel  values  based  on  the  range  of  actual  values 
present 

Segments  an  image  into  two  states  at  a  specified 
threshold  level 
Square  root  function 
Square  function 

Sets  all  values  below  a  specified  level  to  zero 
Twos  complement  of  an  image 
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4.0  WHAT  IS  "STAGEC00E"? 

Stagecode  is  the  data  that  is  loaded  into  a  stage  to  configure 
its  hardware  calculation  circuitry  and  load  constant  registers  and 
lookup  table  RAMs.  This  data  defines  the  transformation  to  be 
performed  by  the  stage.  At  the  hardware  level,  a  stagecode  block  for 
one  hardware  stage  consists  of  790  or  798  bytes  (eight-bit  bytes)  of 
data.  The  longer  798  byte  data  block  is  provided  to  program  Cyto-HSS 
chip  stages.  All  stage  types  (board  and  chip)  support  the  790  byte 
format  data  block. 

C4PL  abstracts  the  data  block  necessary  to  program  the  stage  into 
two  distinct  types.  These  types  are  neighborhood  transform  operations 
and  point  transform  operations.  Although  one  hardware  stage  can  be 
programmed  to  perform  two  transforms  simultaneously  (one  of  each 
type),  C4PL  (for  reasons  of  logical  clarity  and  system  software 
considerations  relating  to  the  handling  and  optimization  of  sequences 
of  stage  operations)  deals  in  stage  code  blocks  of  these  two  distinct 
types.  These  stage  code  types  will  be  discussed  in  detail  in 
subsequent  sections. 

At  this  point,  we  must  clarify  the  terminology  used  in  C4PL 
regarding  stage  code  blocks.  C4PL  handles  stage  program  information 
in  a  hierarchically  structured  way.  At  the  lowest  level  are  the 
actual  data  values  that  will  ultimately  be  programmed  into  the  stage 
hardware  registers  and  lookup  tables.  Groupings  of  this  data  are 
formed  to  create  the  two  distinct  types  of  transformations  possible  in 
the  stage.  These  data  blocks  are  known  as  "stageops,"  or  stage 
operations.  Stageops,  in  turn,  are  grouped  into  sequences  that  can  be 
identified  uniquely  in  C4PL  as  "stagecode"  and  stored  in  C4PL 
variables.  A  stagecode  variable  in  C4PL  amounts  to  a  list  of 
identifiers,  each  of  which  identifies  a  stageop.  A  stageop  can  exist 
independently  in  a  C4PL  variable,  although  this  is  unusual.  The 
hierarchy  of  stage  program  data  organization  is  shown  in  Figure  1: 
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Stagecode: 


Stageops : 


!  *ops| 
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| pgmdata | 

stage 
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program 
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|  etc . . .  | 

I 

data 

i 

FIGURE  1.  Hierarchy  of  Stage  Program  Data  Organization 

Fundamentally,  it  is  the  stage  program  data  in  stageops  that  one 
creates  and  modifies  to  produce  unique  image  transformations  to  be 
performed  within  the  Cyto-HSS  stage.  However,  the  current  context  of 
stage  data  may  vary  depending  on  how  it  is  created  or  manipulated,  and 
this  context  must  always  be  kept  in  mind.  Stage  data  may  be  created 
directly  and  stored  in  C4PL  array  variables;  or  it  may  exist  as  a 
stageop  variable  where  it  is  accessed  by  indexing;  or  it  may  only 
exist  in  the  context  of  a  stagecode  variable,  where  it  may  still  be 
accessed  through  indexing.  Indexing  into  stageops  must  take  into 
account  the  header  information  resident  in  the  stageop  variable. 

Stage  program  data  is  always  of  C4PL  type  T_BYTE,  that  is, 
eight-bit  unsigned  integers.  Calculations  used  to  produce  stage 
program  data  may  use  higher  precision,  but  a  scaling  or  truncation 
operation  must  be  performed  prior  to  placing  such  data  in  stagecode. 
For  example,  data  may  be  created  as  T_I NT  (32-bit  signed  integer) 
arrays,  then  placed  in  stagecode  through  the  ArrayToCode  command. 

This  command  requires  T_BYTE  type  data  as  input,  so  the  T_INT  array 
must  be  explicitly  converted  to  T_BYTE  prior  to  use  of  the  ArrayToCode 
command.  This  conversion  may  be  done  with  the  MakeArray  command. 

The  structure  and  content  of  stageops  will  now  be  defined 
further.  Point  transformation-type  stageops  will  be  discussed  first, 
then  neighborhood  transformation-type  stageops  will  be  described.  In 
the  discussions  that  follow  it  is  assumed  that  the  reader  has  reviewed 
the  Stage  Programmer's  Manual  [1]  to  gain  some  familiarity  with  the 
operations  that  are  performed  within  the  stage. 
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4.1  POINT  TRANSFORMATIONS 

The  PRAM  (Point  Random  Access  Memory)  operation  is  a  simple 
mapping  of  each  pixel  value  to  some  new  value.  A  input  pixel's 
neighbors  have  no  effect  on  this  operation.  A  PRAM  stageop  data  block 
consists  of  information  about  the  contents  of  the  256-byte  PRAM  in  the 
stage.  A  PRAM  operation  is  expressed  mathemati cal ly  and  graphically 
in  Figure  2: 


new_c  =  f(c) 

.  f  . 

|  c  |  -->  j  new_c  j 


FIGURE  2.  A  PRAM  Operation 

Stageops  of  the  point  transform  type  are  arrays  of  bytes  in  the 
order  and  with  meanings  as  shown  in  Figure  3: 


|  optype  (PRAM) 

1  RAMtype  (RAW, ASCEND , DESCEND) 

|  PRAM  0  (not  present  if  RAMtype  ~=RAW) 

|  etc... 

|  PRAM  256  (not  present  if  RAMtype  ~=RAW) 


FIGURE  3.  Organization  of  PRAM  Stageop  Data 


4.1.1  QpType 

The  first  byte  of  all  stageops  defines  the  type  of  stageop. 
Point  transformation  operations  have  the  predefined  type  PRAM. 


4.1.2  RAMtype 

The  second  byte  defines  the  PRAM  section  of  the  subsequent  data 
in  the  block.  Three  options  are  defined:  RAW,  ASCEND,  and  DESCEND. 
RAW  means  that  all  256  locations  of  the  PRAM  are  explicitly  specified 
by  256  bytes  of  data  that  follow  the  RAMtype  byte.  ASCEND  indicates 
that  no  data  follows  the  RAMtype  byte,  and  the  PRAM  is  to  be  filled 
with  data  that  defines  a  straight-through  mapping  (i.e., 
data=address) .  DESCEND  indicates  no  data  follows  the  RAMtype  byte, 
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and  the  PRAM  is  to  be  filled  with  an  inverting  mapping 
(i.e.,  data=NOT(address) ) . 


4.1.3  PRAM  Oat a 

Either  0  or  256  bytes  of  data  follow  the  RAMtype  stageop 
parameter,  depending  on  that  parameter's  value.  This  data  will  be 
programmed  into  the  PRAM  lookup  table  within  the  stage  and  defines  the 
desired  PRAM  output  value  for  each  PRAM  input  value  (a  point-to-point 
mapping).  This  RAM  consists  of  256  bytes  due  to  the  8-bit  pixel 
resolution  of  the  stage  and  data  paths  within  the  Cyto-HSS. 


4.2  NEIGHBORHOOD  OPERATIONS 

A  neighborhood  transform  operation  consists  of  data  for  the  stage 
control  registers  (of  which  there  are  22  or  32  depending  on  the  stage 
hardware  to  be  programmed)  and  information  relating  to  the  contents  of 
the  512-byte  NRAM  (Neighborhood  Random  Access  Memory).  Neighborhood 
transform  operations  are  those  operations  that  produce  a  new  pixel 
value  for  each  input  value  based  on  some  function  of  the  original 
pixel  and  one  or  more  of  its  8  neighbors.  This  function  can  be 
expressed  in  Figure  4: 

new_c  =  f(ne,eIse,s,sw,w,nw,n,c) 


|  nw 

n 

ne  | 

f 

1  * 

c 

e  1 

l 

--> 

|  new_c  | 

1  sw 

s 

se  | 

FIGURE  4.  An  NRAM  Operation. 

Stageops  of  the  neighborhood  transform  type  are  arrays  of  bytes 
where  each  byte  has  meaning  as  shown  in  Figure  5: 
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1  optype  (XFORM, XFQRM2)  | 

;  RAMtype  (RAW, LNRAMO, HNRAMO, 80TH0)  j 
control  register  1  j 

|  etc ...  | 

j  control  register  N  (N=22  or  32)  | 

|  NRAM  0  (not  present  if  RAMtype=BQTHO) | 
|  etc...  | 

|  NRAM  N  (not  present,  or  N=256 , 512)  | 


FIGURE  5.  Organization  of  NRAM  Stageop  Data. 

4.2.1  OpType 

The  first  byte  of  all  stageops  defines  the  type  of  stageop. 
Neighborhood  operations  may  be  one  of  two  predefined  types:  XFORM  or 
XF0RM2.  Type  XFORM  specifies  a  short  code  block  containing  22  bytes 
of  control  register  information.  Type  XF0RM2  specifies  the  long 
program  containing  32  bytes  of  control  register  bytes. 


4.2.2  RAMtype 

The  second  byte  defines  the  NRAM  section  of  the  subsequent  data 
in  the  block.  Four  options  are  defined:  RAW,  low-half  NRAM  all 
zeros (LNRAMO) ,  high-half  NRAM  all  zeros  (HNRAMO),  and  both  halves  all 
zero  (BOTHO).  RAW  means  that  all  512  locations  of  the  NRAM  are 
specified  by  512  bytes  of  data  that  follow  the  control  register  data. 
LNRAMO  indicates  that  256  bytes  of  data  follow  the  control  registers 
and  that  these  256  bytes  specify  the  high  half  of  the  NRAM  (the  low 
half  is  to  be  filled  with  all  0  data).  Similarly,  HNRAMO  indicates 
that  256  bytes  follow  the  control  register  data  and  that  these  256 
bytes  specify  the  low  half  of  the  NRAM  (the  high  half  is  to  be  filled 
with  all  0  data).  80TH0  indicates  that  no  NRAM  data  follows  the 
control  registers,  and  that  the  entire  NRAM  is  to  be  filled  with 
zeros . 


4.2.3  Control  Registers 

Control  register  data  is  organized  in  the  order  specified  in  the 
Stage  Programmer's  Manual  [1].  A  XFORM  stageop  will  have  22  bytes  of 
data  and  a  XF0RM2  stageop  will  have  32  byte  positions.  Figure  2  in 
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the  referenced  document  (page  9)  shows  the  layout  and  meaning  of  the 
control  register  data  for  the  22-byte  format.  Figure  6  (page  26) 
shows  the  XF0RM2  register  format.  Note  that  only  31  byte-wide  control 
registers  are  defined  in  the  long  stage  program  format.  The  XF0RM2 
stageop  data  block  definition  allocates  32  bytes  for  the  control 
registers  for  reasons  relating  to  byte/word  alignment.  The  extra  byte 
is  placed  at  the  end  of  the  31  bytes  of  control  register  data  and  the 
value  of  this  byte  is  of  no  importance.  However,  when  indexing  into 
XF0RM2-type  stageops,  this  dummy  byte  must  be  taken  into  account  when 
calculating  offsets  to  access  NRAM  data  bytes  (if  present). 


4.2.4  NRAM  Data 

Either  0,  256,  or  512  bytes  of  data  follow  the  control  register 
data,  depending  on  the  value  of  the  RAMtype  paramter  in  the  stageop 
definition.  This  data  will  De  programmed  into  the  NRAM  lookup  table 
in  ascending  address  order  within  the  stage,  and  defines  the  desired 
NRAM  output  value  for  each  combination  of  neighbor  pixel  test 
condition  evaluation  results.  The  NRAM  consists  of  512  bytes  because 
there  are  9  neighbors  in  the  3  by  3  transformation  window.  The  NRAM 
is  accessed  with  a  9-bit  add'-ess  formed  by  the  result  (true/false)  of 
the  programmed  evaluation  condition  (as  specified  by  the  control 
registers)  for  each  of  the  nine  neighbors.  The  bit  position 
assignmert  within  this  address  for  each  neighbor  test  result  begins 
with  the  northeast  neighbor  at  bit  0  (the  low-order  bit)  and  proceeds 
clockwise  around  the  3  by  3  window.  The  center  pixel  test  result 
provides  bit  8  (the  high-order  bit)  of  the  NRAM  address  vector. 
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5.0  WHY  MESS  WITH  STAGECODE  DIRECTLY? 

Many  C4PL  users  will  never  need  to  understand  nor  manipulate 
stagecode  directly.  The  C4PL  language  exists  to  provide  an  abstract, 
structured,  and  powerful  "front-end"  to  the  Cyto-HSS  hardware.  The 
language  shields  the  user  from  having  to  be  knowledgable  about  the 
intricacies  of  the  hardware  itself  and  from  having  to  program  image 
transformation  operations  at  a  language  level  that  is  unsuited  to  the 
operation  being  performed. 

There  may  come  a  time,  however,  when  the  user  wants  to  perform  an 
operation  that  doesn't  quite  fit  within  the  parametric  constraints  of 
the  commands  provided  by  C4PL.  It  is  also  possible  to  conceive  a 
stage  operation  unlike  anything  that  C4PL  provides  (this  is  an  unusual 
situation  given  the  breadth  of  commands  and  options  within  C4PL). 

These  are  the  times  when  direct  stagecode  manipulation  or  generation 
may  be  required. 


5.1  MODIFICATION  OF  STAGECODE 

An  example  of  a  minor  modification  to  an  existing  C4PL  command 
follows.  Suppose  you  want  to  find  all  4-way  connected  cross  points  of 
pixels  in  state  5.  A  Match  command  specification  to  do  this  and  save 
the  resulting  stagecode  is  as  follows: 

declare  code  ;  create  a  variable  to  hold  stagecode 

Match  2  ~5  5  ~5  &  ;  create  transformation,  put  in  code 

5  5  5  & 

~5  5  ~5  ->  .code 


The  code  that  results  from  this  Match  command  is  a  XFORM-type 
stageop  that  would  program  all  neighbor  contribution  values  to  equal 
-5,  set  the  test  condition  for  each  neighbor  for  "equal  0",  and  put 
the  output  state  (2)  in  appropriate  locations  in  the  high  half  of  the 
NRAM.  All  other  locations  in  the  NRAM  would  be  set  to  zero.  The  NRAM 
address  vector  generated  in  the  neighborhood  calculation  logic  in  the 
stage  would  produce  an  NRAM  output  of  either  0  or  2,  depending  on 
which  neighbors  pass  the  test.  The  output  selection  logic  would  pass 
the  NRAM  output  on  to  the  PRAM  if  it  is  non-zero,  or  the  original 
center  pixel  value  if  the  NRAM  output  is  zero.  The  PRAM  (although  not 
specified  in  the  stagecode  that  results  from  this  Match  command)  would 
be  set  to  an  data=address  or  "straight"  pattern  to  pass  the  output  of 
the  output  selection  logic  through  unaltered. 

Now,  suppose  you  want  to  mark  all  cross  points  having  a  center 
pixel  state  of  5  or  greater.  The  Match  command  does  not  allow  a  pixel 
state  specification  of  ">=5"  or  ">4",  so  the  desired  transform  cannot 
be  specified  directly.  But  the  stage  can  perform  this  desired 
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operation.  A  "greater  than  or  equal  to  5"  test  on  the  center  pixel 
value  can  be  specified  by  setting  the  test  condition  for  the  center  to 
check  for  a  ""carry"  instead  of  an  "equal  to."  Stagecode  to  perform 
this  modified  Match  operation  can  be  generated  using  the  code  that 
results  from  the  Match  command  above  and  modifying  it  as  follows: 

;  define  symbol  for  15th  byte  of  stageop  (center  control) 
syn  c_control  "15" 

;  neighbor  test  control  bits  =  "01"  (carry  out) 
syn  carry_out  "2" 

;  change  center  test  to  carry  instead  of  equal  zero 
code[l] [c_control]  :=  code[l] [c_control]  |  carry 


This  operation  modifies  the  Test  Control  bits  (TC1.TC0)  in  the 
neighbor  control  register  for  the  center  pixel  to  select  the  "carry" 
(0,1)  condition  instead  of  the  "equal  zero"  condition  (0,0).  There  is 
only  one  stageop  in  "code"  (since  it  was  declared  just  prior  to  the 
Match  command),  hence  the  first  index  is  1.  The  second  index,  or 
offset  into  the  neighborhood  transform  stageop  is  15.  This  value  is 
required  because  the  center  pixel  neighbor  control  register  is  the 
13th  byte  of  the  stage  program  (see  Figure  2,  page  9  of  the  Stage 
Programmer's  Manual  t 1] ) .  and  there  are  two  "header"  bytes  at  tne 
begining  of  the  stageop  that  define  its  type  and  RAM  data  content. 


5.2  GENERATION  OF  STAGECODE 


An  example  of  an  operation  created  by  direct  generation  of 
stagecode  follows.  When  no  C4PL  command  exists  that  can  produce 
stagecode  similar  to  what  is  needed,  then  direct  generation  of 
stagecode  in  arrays  is  appropriate.  Suppose  a  unique  scaling 
operation  was  desired  that  would  transform  an  image  containing  pixel 
values  in  the  range  of  0  to  255  to  the  range  of  128  to  255.  This 
could  be  done  with  a  PRAM  operation  in  a  stage  that  maps  each  adjacent 
pair  of  input  values  to  one  output  value  (0  and  1  map  to  128,  2  and  3 
map  to  129,  ...,  254  and  255  map  to  255).  A  PRAM  stageop  to  do  this 
transformation  can  easily  be  generated  as  follows: 


declare  pramarray,code, i 
makearray  T_BYTE  256  ->  pramarray 
for  i  0  255 

pramarray[i+l]  :=  (i/2)+128 
endfor 

arraytocode  pramarray  ->  ,code 


;  array, code, loop  vars 
;  256  byte  array 
;  fill  with  map  data 


;  convert  to  stagecode 


In  both  of  the  examples  above,  the  resulting  stagecode  in  the 
variable  "code"  can  be  applied  to  images  with  the  Apply  command: 
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apply  code  1  inputimage  ->  outputimage  ;  execute  stagecode  "code"  one 

More  complex  examples  of  stagecode  modification  and  generation 
are  given  later  in  this  document. 
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6.0  C4PL  FEATURES  USEFUL  FOR  STAGECODE  OPERATIONS 

There  are  several  commands  and  features  of  the  C4PL  language  that 
allow  and  facilitate  direct  operations  on  and  generation  of  stagecode. 
A  brief  description  of  each  of  these  commands  and  features  is 
presented  below.  For  more  detailed  information,  the  C4PL  User's 
Manual  [2]  or  on-line  help  explanations  may  be  referenced. 


6.1  C4PL  STAGECODE  GENERATING  COMMANDS 

As  seen  in  previous  sections,  there  are  dozens  of  commands 
available  in  C4PL  that  generate  stagecode.  For  many  applications, 
these  commands  provide  more  than  enough  power  and  flexibility  to 
process  images  as  required,  without  the  user  having  to  have  any 
detailed  knowledge  of  the  stagecode  that  these  commands  produce. 

Any  C4PL  or  EPICAL  command  of  the  form 

CommandName  pl,p2...  inputimage  ->  outputimage,  code 

returns  the  stagecode  it  generates  to  perform  the  requested  operation 
as  an  optional  output.  Stagecode  is  appended  to  variable  "code"  if  it 
is  specified.  If  "code"  is  not  already  a  stagecode  variable,  it  will 
be  converted  to  one. 

This  command  syntax  for  stagecode  generating  commands  allows  any 
of  these  commands  to  be  utilized  for  generation  of  stagecode  for 
subsequent  customization  by  the  user.  The  resulting  code  can  be 
accessed  directly  by  indexing  into  the  stagecode  variable,  or  the 
stageop  or  stageops  contained  in  the  stagecode  variable  can  be 
converted  into  arrays  for  subsequent  manipulations. 

The  Match  command  is  particularly  useful  for  creating  a 
neighborhood  transform  stageop,  and  Cover  is  one  command  that  may  be 
used  to  produce  a  point  transformation  (PRAM-type)  stageop. 


6.2  ARRAYT0C0DE  COMMAND 

This  command  allows  the  user  to  put  data  from  C4PL  arrays  (of 
bytes)  into  a  stagecode  variable.  The  command  does  all  the  processing 
necessary  to  construct  the  appropriate  stageop  and  attach  it  to  the 
specified  stagecode  variable.  Two  different  forms  of  the  command 
exist,  one  for  each  type  of  stageop  in  C4PL: 

ArrayToCode  INRAM  hNRAM  cntlregs  inimage  ->  outimage,  code 

ArrayToCode  PRAMarray  inimage  ->  outimage,  code 
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Note  that  this  command  has  the  same  syntax  as  any  other  stagecode 
generating  command  in  C4PL.  The  stage  operation  will  be  executed 
immediately  with  the  specified  images  if  the  "code”  variable  is  not 
specified.  Otherwise,  the  stageop  that  results  from  the  specified 
array  data  is  appended  to  the  "code"  variable. 


6.3  CODETOARRAY  COMMAND 

This  command  is  the  inverse  operation  to  ArrayToCode.  It  also 
has  two  forms: 

CodeToArray  code  opnumber  ->  lowNRAM  highNRAM  control regs 

CodeToArray  code  opnumber  ->  PRAMarray 

The  “opnumber"  parameter  specifies  which  stageop  is  to  be 
converted  from  the  list  of  stageops  contained  in  "code".  Although 
stageops  may  be  manipulated  directly  via  indexing,  conversion  to 
arrays  may  be  useful  in  some  cases  to  allow  calculations  on  the  stage 
program  data  to  be  done  at  higher  precision. 


6.4  APPLY  COMMAND 

Apply  provides  the  means  for  executing  stagecode  once  it  has  been 
generated  and  stored  in  a  stagecode  variable.  The  syntax  is: 

Apply  stagecode  passes  inputimage  ->  outputimage 

The  same  stagecode  may  be  executed  multiple  times  on  the  same 
inputimage  by  specifying  a  "passes”  parameter  greater  than  1. 


6.5  ARRAY  OPERATIONS 

Array  operations  and  subarray  notation  in  C4PL  can  provide 
efficient  means  of  creating  stage  program  data  in  arrays.  Arrays  in 
C4PL  are  similar  to  arrays  in  other  programming  languages.  Whole 
arrays  can  be  specified  as  operands  for  arithmetic,  relational,  and 
assignment  operators.  Array  elements  are  referenced  in  the  usual  way 
via  an  array  name  with  subscripts. 

Subarray  notation  provides  convenient  access  to  subsets  of 
arrays.  It  allows  users  to  easily  manipulate  array  information 
without  the  use  of  time-consuming  loops  and  element-by-element 
indexing. 
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Stageops  in  C4PL  can  be  treated  as  arrays.  Images  in  C4PL  can 
also  be  accessed  and  treated  as  arrays.  These  capabilities  present  a 
number  of  interesting  possibilities,  such  as  using  image  processing 
operations  to  create  data  in  an  image  which  can  then  be  converted  to 
and  used  as  stagecode. 

Array  operations  on  stageops  will  only  affect  the  stage  data. 

The  optype  and  RAMtype  header  bytes  will  be  unaffected.  For  example, 
if  "code"  is  a  stagecode  variable  containing  one  PRAM  type  operation 
(that  has  a  "RAW"  or  fully  specified  256-byte  data  block),  then  that 
PRAM  stageop  may  be  directly  set  to  all  one  value  (e.g.,  255)  with  the 
following  subarray  expression: 

code[lj{*]  :=  255 

Please  refer  to  the  C4PL  User' s  Manual  section  4.2.3. 1  "Arrays" 
for  detailed  information  on  arrays  and  subarray  notation  [2],  or 
access  the  on-line  help  information. 


6.6  STAGECODE  ARRAY  INDEXING 

Array  indexing  of  stagecode  variables  is  possible  in  C4PL.  This 
makes  direct  array  operations  on  stageops  contained  in  stagecode 
variables  available  to  the  user.  Care  must  be  taken  to  insure  that 
the  desired  data  is  being  accessed  at  all  times,  however. 

Recall  that  a  stagecode  variable  is  a  list  of  identifiers  of 
stageops,  which  actually  hold  the  stage  program  data.  The  stageop 
which  has  the  data  also  has  a  two  byte  header  in  it  to  identify  the 
type  of  operation  and  the  type  and  amount  of  RAM  data  it  contains.  An 
indexed  reference  to  a  data  location  in  a  stageop  contained  in  a 
stagecode  variable  must  identify  which  stageop  is  being  referenced  as 
the  first  index,  and  the  byte  in  the  referenced  stageop  as  the  second 
index.  For  example,  the  first  stage  data  byte  of  a  XFORM  type  stageop 
which  is  the  first  stageop  in  a  stage  code  variable  "code"  can  be 
accessed  as  follows  (note  that  in  C4PL,  all  arrays  are  one-origin): 

mode_control  :=  code[l][3] 

Note  that  3  is  specified  as  the  second  index.  This  locates  the 
first  stage  data  byte  (the  Mode  Control  register).  The  first  two 
bytes  of  the  XFORM  stageop  identify  the  stageop  type,  and  the  RAM 
type.  The  syntax  is  [m] [n]  because  each  index  represents  an  index 
into  a  different  one  dimensional  array.  A  syntax  of  [m,n]  would 
represent  a  particular  element  of  a  single  two  dimensional  array. 


6.7  BIT-WISE  LOGICAL  OPERATORS 

The  relational  operators  &  (logical  AND),  |  (logical  OR),  and  ~ 
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(logical  NOT)  are  very  important  for  modifying  particular  bits  in 
stage  program  data  bytes.  Several  stage  program  bytes  contain  bits  or 
bit  subsets  that  control  stage  operation.  These  program  bytes  include 
Mode  Control,  the  bit  masks  (Input  and  Output),  and  the  nine  Neighbor 
Control  registers. 


6.8  R0TATEC00E  COMMAND 

RotateCode  "rotates'1  the  first  stageop  in  a  stagecode  variable. 
The  stageop  must  be  a  neighborhood  transform  type  stageop  (rotation  of 
PRAM-type  stageops  has  no  logical  meaning).  Rotation  in  this  context 
refers  to  the  rotation  of  the  neighbor  program  data  about  the  center 
in  the  3  by  3  neighborhood.  Consider  a  stagecode  variable  produced 
with  a  Match  command,  such  as: 

Match  2  #  ~1  ~1  & 

1  1  ~1  & 

#  ~1  ~1  ->  .StageCode 

A  rotation  of  this  StageCode  by  90  degrees  produces  a  different 
stagecode: 

RotateCode  StageCode  90  ->  ,New$tageCode 

that  is  equivalent  to  a  Match  command  specified  as  follows: 

Match  2  #  1  #  & 

~1  1  ~1  & 

~1  ~1  ~1  ->  .NewStageCode 

Rotation  of  a  stageop  is  accomplished  by  rotating  the  8  neighbor 
control  registers,  the  8  neighbor  contribution  values,  and  rearranging 
the  NRAM  appropriately.  In  a  90-degree  rotation  the  north-east 
neighbor  control  and  contribution  would  take  on  the  values  previously 
contained  in  the  north-west  control  and  contribution  registers.  In 
all,  each  neighbor  register  value  would  shift  two  positions  around  the 
neighborhood  in  a  clockwise  direction.  The  NRAM  rearrangement  is 
somewhat  complicated  at  first  glance,  but  it  is  simply  a  rearrangement 
of  data  within  the  NRAM  according  to  a  rotation  of  the  bits  comprising 
the  NRAM  address  vector.  The  bits  of  the  9-bit  vector  correspond  to 
neighbors  as  follows: 

C  N  NW  W  SW  S  SE  E  NE 

8  7  6  5  4  3  2  1  0 

Keep  in  mind  that  the  NRAM  is  a  bl2-byte  array  with  address 
values  from  0  to  511,  and  therefore  a  rotation  of  90  degrees  maps  the 
ongina1  data  contained  in  each  NRAM  location  to  a  new  location 
specified  by  an  address  which  is  the  original  address  with  the 
low-order  8  bits  rotated  left  (with  wrap).  For  example,  the  NRAM  data 


32 


J>ER1M _ 

at  address  1  (NE  bit  ON)  would  be  placed  in  the  new  NRAM  at  address  4 
(SE  bit  ON).  Since  the  center  does  not  rotate,  each  NRAM  half  is 
treated  independently.  Therefore,  a  90  degree  rotation  would  also 
take  the  data  from  address  257  (NE,C  bits  ON)  and  place  it  at  new  NRAM 
address  250  ( SE , C  bits  ON),  and  so  on. 


6.9  ROTATEARRAY  COMMAND 

The  RotateArray  command  provides  the  same  capability  to  rotate 
stage  program  data  as  the  RotateCode  command;  however,  RotateArray 
operates  on  data  stored  as  arrays.  This  command  allows  input  arrays 
of  22  bytes  (a  standard  stage  control  register  block),  31  or  32  bytes 
(a  long  .stage  control  register  block),  and  256  bytes  (an  NRAM  half). 
The  syntax  is  the  same  as  the  RotateCode  command. 


6.10  ASCENDING_PRAM 

At  some  point  in  the  near  future,  C4PL  will  have  a  system 
constant  256-byte  array  containing  data  whose  value  equals  the  array 
index  (an  "ascending"  PRAM).  This  feature  will  relieve  the  user  from 
having  to  generate  this  type  of  data  block.  This  type  of  array  is 
commonly  used  as  a  basis  for  customized  PRAM  stageops  and  will  allow 
more  efficient  generation  of  stagecode. 


6.11  STAGEDEFS 

An  include  file  of  C4PL  synonyms  for  the  stage  program  register 
offsets  and  bit  offsets  into  those  registers  that  contain  programming 
switches  will  be  available  in  C4PL.  Descriptive  names  for  the  numeric 
offsets  into  arrays  containing  stage  program  data  greatly  enhances  the 
readability,  debugging  and  maintenance  of  procedures  which  generate 
stagecode. 


6.12  PRAMSET  COMMAND 

The  PramSet  command  has  the  form: 

PramSet  Stateln  StateOut  Mask  InputArray  ->  OutputArray 

The  PramSet  command  is  similar  to  the  Cover  command,  except  the 
input  and  output  variables  are  arrays.  It  puts  the  masked  value  of 
StateOut  in  all  locations  corresponding  to  an  address  of  Stateln 
(under  the  specified  mask). 

The  purpose  of  a  PRAM  stageop  is  to  map  a  particular  input  value 
to  a  new  value.  When  the  stage  input  and/or  output  masks  are  in  use, 
the  desired  PRAM  mapping  becomes  a  little  complicated.  Masks  are 
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typically  used  to  prevent  whatever  neighborhood  operation  is 
programmed  in  a  stage  from  affecting  particular  bits  of  the  image. 


Suppose  we  are  using  the  low-order  bit  of  the  image  being 
processed  to  hold  some  interesting  information  and  we  don't  want 
operations  on  the  rest  of  the  bits  to  affect  the  low-order  bit  state. 
Now  suppose  we  want  to  map  pixel  state  2  to  state  4.  In  this 
situation  we  would  call  the  PramSet  command  with  Stateln  =  2,  StateOut 
=  4,  Mask  =  254  (OxFE) ,  and  the  input  array  is  ascending  or  straight 
(date=address) .  PramSet  will  create  an  output  array  based  on  the 
input  array  as  follows: 

Original:  Modified: 


Location  0:  0  0 
Location  1:  1  1 
Location  2:  2  4 
Location  3:  3  5 
Location  4:  4  4 
Location  5:  5  5 
Location  6:  6  6 


The  C4PL  code  fragment  that  implements  the  PramSet  command  is  a 
good  example  of  the  use  of  logical  operators  and  array  expressions  in 
C4PL. 

statein  :=  statein  &  mask 

stateout  :=  stateout  &  mask 

bool  :=  (ascending_pram  &  mask)  =  statein 

outpram  :=  inpram  *  (~bool)  +  (  stateout  |  inpram* (~mask)  )  *  bool 
makearray  T_BYTE  256  ->  outpram 

Ascending_pram  is  a  predefined  256-byte  array  whose  data=address. 

Bool  is,  therefore,  an  array  of  boolean  values  that  defines  the 
addresses  of  the  PRAM  that  will  be  modified  with  the  stateout  value. 
The  outpram  then  takes  on  either  the  corresponding  value  from  the 
inpram  or  a  new  value  that  is  a  combination  of  bits  from  stateout  and 
the  corresponding  inpram  value  as  determined  by  the  specified  mask. 


6.13  PRAMSWAP  COMMAND 

PramSwap  swaps  two  values  in  a  PRAM  array  under  control  of  a 
bitmask.  This  command  is  used  when  it  is  desired  to  exchange  two 
values  in  an  image  and  is  specified  as  follows: 

PramSwap  Statel  State2  Mask  InputArray  ->  OutputArray 
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PramSwap  puts  the  masked  value  of  Statel  in  all  locations 
correspondi ng  to  an  address  of  State2  (under  mask).  It  also  puts  the 
masked  value  of  State2  in  all  locations  correspondi ng  to  an  address  of 
Statel  (under  mask).  PramSwap  is  implemented  in  C4PL  by  a  procedure 
that  makes  two  calls  to  the  PramSet  routine. 


6.14  STAGEANALYZE  COMMAND 

This  command  in  C4PL  is  essential  for  the  programmer  who  is 
attempting  to  generate  user-defined  stageops.  Stageanalyze  is  a 
utility  that  "disassembles"  stageops.  It  provides  a  formatted  output 
detailing  the  programming  information  contained  within  a  stageop  or 
series  of  stageops. 


6.15  OTHER  USEFUL  COMMANDS 

Several  other  C4PL  commands  and  functions  are  typically  used  in 
the  construction  of  a  C4PL  procedure.  Most  of  the  commands  and 
functions  listed  below  are  described  in  the  C4PL  User1 s  Manual , 

Chapter  5  -  Procedures  [2] . 

Procedure  syntax:  Procedure,  EndProcedure. 

Variables/constants:  gdeclare,  declare,  syn. 

Argument  checking:  findarg_type,  typeof,  setdef,  setret,  etc. 

Interactive/information:  input,  pause,  wait,  print,  print!. 

Control  flow:  break,  for,  if,  repeat,  while,  etc. 

Stagecode  handling:  loadcode,  storecode,  runout. 

One  good  way  to  become  familiar  with  C4PL  procedure  writing  is  to 
examine  several  of  the  built-in  procedures  that  implement  many  C4PL 
commands. 


~¥erim _ 

7.0  ARRAYS  VERSUS  OIRECT  STAGECODE  REFERENCES 

In  general,  it  is  somewhat  safer  and  perhaps  easier  to  deal  with 
stage  program  data  as  arrays.  The  question  of  whether  to  build  and 
manipulate  stage  program  data  as  arrays  or  in  the  form  of  stageops  is 
dependent  on  context,  however.  Which  should  be  used  depends  on  the 

data  that  is  to  be  created,  and  how  it  is  to  be  used  or  modified. 

Three  reasons  exist  for  operating  in  the  array  domain  when 
creating  and  manipulating  stage  program  data.  First,  indexing  into 
stageops  is  more  prone  to  error  due  to  a  need  to  account  for  the  two 
bytes  of  header  information  in  each  stageop.  This  means  that  indicies 
for  stageop  data  are  offset  by  two  from  their  usual  value.  The 
correct  index  for  the  desired  stageop  must  also  be  provided  when 
accessing  a  stageop  contained  in  a  stagecode  variable.  Second, 

stageops  are  often  encoded  in  compacted  form  through  the  use  of  the 

RAMtype  header  byte.  The  stage  programmer  must  take  care  that  each 
stageop  being  manipulated  is  well  understood  and  that  the  RAM  contents 
of  the  stageop  are  known.  C4PL  will  enforce  array  index  limitations 
on  stageops  as  well  as  arrays,  but  this  does  not  guarantee  that  the 
programmer  knows  what  kind  of  stageop  is  being  manipulated.  A 
XFORM-type  stageop  may  contain  256  bytes  representing  the  high  NRAM 
half,  but  a  programmer  might  erroneously  assume  that  this  RAM  data 
represents  the  low  NRAM  half  (and  will  never  know  the  difference 
unless  the  RAMtype  byte  is  checked,  or  until  erroneous  image 
transforms  occur).  Third,  stageops  in  C4PL  are  entities  that  are 
utilized  through  reference,  rather  than  instance.  This  means  that  it 
is  possible  for  multiple  stagecode  variables  to  exist  that  have 
references  to  the  same  stageop.  A  change  to  the  stageop  made  via  an 
array  reference  through  one  stagecode  variable  will,  therefore,  affect 
the  other  stagecode.  If  this  linkage  between  stagecode  variables  is 
unknown  to  the  programmer,  unexpected  results  will  obviously  follow. 

After  having  made  a  strong  case  for  using  arrays  to  work  with 
stage  program  data,  a  qualifier  must  be  inserted.  In  instances  where 
the  stageops  to  be  modified  are  well  understood,  and  care  is  taken  to 
index  into  them  correctly;  then  it  is  more  efficent  to  access  the 
stageops  directly  rather  than  convert  them  to  arrays,  make  changes, 
then  convert  them  back  to  stagecode. 
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As  previously  noted,  several  examples  of  stagecode  generating 
procedures  exist  within  C4PL  itself.  Procedures  implement  many  of  the 
EPICAL  image  processing  commands.  The  C4PL  procedure  directory  on 
your  system  is  accessible  and  these  procedures  can  be  copied  to  the 
user's  directory.  This  is  an  ideal  way  to  get  a  running  start--use  an 
existing  procedure  file  as  a  template  and  modify  it  as  needed. 
Procedures  are  stored  on  VAX/VMS  systems  in  a  directory  pointed  to  by 
the  C4PL  defined  logical  name  “c4pl $proc" .  On  other  systems,  the 
appropriate  directory  may  be  deduced  by  looking  at  the  default 
command_search  search  list  for  any  directories  that  are  used  to 
reference  "*.def"  files. 


8.1  MARKTEES 

This  EPICAL  procedure  is  a  simple  example  of  the  use  of  the  Match 
command  to  build  up  a  more  complex  image  transformation.  It  does  not 
perform  special  stagecode  manipulations.  It  is  included  here  as  an 
example  to  point  out  that  unique  or  specialized  image  transformations 
can  be  built  out  of  existing  C4PL  library  commands  without  necessarily 
having  to  resort  to  direct  stagecode  generation  or  manipulation.  This 
code  is  a  simplified  version  of  the  actual  C4PL  routine. 
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'°cce:ure  name 

-*5S~:?AuT : 
ENVIRONMENT : 
SPECIFICATION: 


OESCRIPTION: 


INPUT  PARAMS: 


OUTPUT  OATA: 

H I  STORY : 

Rev 

0.0 

3.1 

0.2 


-  V  ’  ■-onnent  a : 


3esearc 


‘A  , 


can 


MarkTees 

Mark  T-connect : ons  of  lines  :n  state  FGState' 

CAPL  72.5 

MarkTees  FGState  "eeState  Connectivity 

Inputlmage  ->  Outputlmage  StageCode 

States  0  thrcugn  255  are  valid  input  parameters.  For  illegal 
values,  an  er^or  message  will  be  output  to  the  terminal. 

The  input  'mage  is  assumed  to  be  the  binary  ’mage  of  a 
skeleton  in  'GState'  in  rectangular  or  hexagonal  coordinates. 
The  output  image  is  a  binary  image  with  the  centers  of  the 
tees  in  'TeeState',  provided  that  these  centers  were  in 
'FGState'  in  the  original  image. 

All  pixels  in  state  'FGState'  in  the  input  image  which 
are  the  triple-points  (or  "tees)  of  FGstate  lines  are 
changed  to  the  TeeState.  The  connectivity  parameter 
determines  the  conf iguration  used  by  this  procedure. 

The  word  'configuration'  represents: 

N-E-S-W  if  'connectivity'  is  A  and  we're 

in  rectangular  mode 

N-NE-E-SE-S-SW-W-NW  if  'connectivity1  is  8  and  we’re 

in  rectangular  mode 

N-NE-E-SE-S-W  if  we're  in  hexagonal  mode 


FGState: 

foreground  state 

default:  1 

-  find  tees  in  this  state) 

TeeState: 

output  state 

default:  2 

-  mark  tees  found  by  changing 

them  to  this  state) 

Connectivity: 

connectivity 

default:  4 

-  4  =  4-way  connectivity  assumed  for 

input  image 

-  8  3  8-way  connectivity  assumed  for 

input  image 

-  illegal  values  take 

default 

Inputlmage: 

input  image 

default:  active 

Outputlmage: 

output  image 

default:  active 

StageCode: 

stage  cod'  repository 

default:  default 

(execute  it) 

Date 

Author  Description 

08  JAN  90 

1  '•t  original  code  -  derived  from  Pascal 

external  task 

25  JAN  90 

:'m  optimized  via  array 

expressions 

02  FES  90 

clean  up  comments; 

change  array  name; 

mask  contribution  bits  with  input  mask 
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-  -  •- 

"ur  :-o 

'  **  t  a  ‘  * 

*  •  z  r  '  "  3: :  e 

:c  ce  '  as: 

•  . :  ;  5 

-O'*  }0 

:mL  3pn' 

acec  '  zz'  z 

* ■  in  ■uacc'’  c: 

rr.erei 

^ <  13 

■Jun  90 

:a<  3*dlDi  “Or 

examp'e 

r  -■’» 

ecu  re  rGState, 

tats 

Tornect ; v i ty , 

In  Image) 

->  Outlmage, 

StgCcde 

Zee  ’ 

a ro  ;m  pos, 

4 

;  oosition  on  -mage 

arg  in  inout 

oaram  ? ; st 

*  ,7i  rum, 

4 

;  number 

of  image  type  inout  oarams 

der  num 

;  numoer 

of  default 

input  params 

syn 

min  state 

■O'. 

;  define 

/ a 1  id  state 

value  range 

syn 

max_state 

'255  ' 

Set  defaults  for  the  arguments  here. 


setdef  1  ->  FGState 
setdef  2  ->  TeeState 
setdef  4  ->  connectivity 
setdef  active  ->  Inlmage 

setret  active  ->  Outlmage 

;  ****************«»****»»*»**'-**  Check  input  parameters. 

if  ( (type_of (FGState)  o  TJEFAULT)  &  (type_of (FGState)  o  T_  I  NT) ) 

ERROR  Foreground  State  must  be  an  integer." 
elseif  ((FGState  <  min_state)  j  (FGState  >  max_state)) 

ERROR  "***  Foreground  state  must  be  a  value-from  0  to  255.'' 
e: sei f  ( (type_of (TeeState)  o  T_0£FA(JlT)  &  (type_of (TeeState)  o  T_INT) ) 
ERROR  "***  Output  state  must~be  an  integer." 
elseif  ((TeeState  <  min_state)  |  (TeeState  >  max_state)) 

ERROR  "***  Output  state  must  be  a  value  from  0  to  255." 
end  i  f 


if  ((typejjf (connectivity)  o  T_0EFAULT)  &  (type_of (connectivity)o  T  INT) ) 
ERROR  Connectivity  must~be  an  integer." 
elseif  ((type_of(connectivity)  =■  T_I NT )  &  (connectivity  «o  4)  & 

&  (connectivity  o~ 8)) 
connectivity  :=•  4 

printl  "***  MarkTees  --  Warning:  Connectivity  has  been  changed  to  4.” 

endi  f 


.  Tell  user  if  funny  bit  masks  are  used. 

if  ((INMASK  o  255)  |  (OUTMSK  o  255)) 

printl  "***  MarkTees  --  Warning:  Funny  bit  mask  is  in  use." 
endif 


syn  fg  "FGState" 

If  HexMode 

Match  TeeState  "fg  FG  4 

FG  FG  "fg  J 

"fg  FG  2  Inlmage  ->  Outlmage, stgcode 
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E’tal*  ::~-e/:z  1  <  •  ty=4)  ; 'ectanguiar  ncae 

”  J  *  £ 

F'j  "j  4 

*  >  -t  Inlmage  ->  Outlmage, stgcode 

E'self  'connect1 vi ty=3) 

Match  Tee$tate  f  *  r3  4 

~fg  —  ~cg  4 

FG  "fg  FG  3  OR 

Match  TeeState  "fg  *  FG  4 

#  FG  '"fg  4 

FG  ~fg  FG  3  OR 

.Match  TeeState  #  ~fg  FG  4 

*  FG  "fg  4 

FG  ~fg  FG  3  OR 


Match  TeeState  "fg  #  FG  4 

FG  FG  ~fg ‘  4 

"fg  #  FG  3  OR 

Match  TeeState  #  "fg  FG  4 

FG  FG  "fg  & 

*  "fg  FG  8  OR 

Match  TeeState  "fg  #  FG  & 

FG  FG  "fg  & 

#  "fg  FG  8  OR 

Match  TeeState  #  "fg  FG  4 

FG  FG  "fg  4 

"fg  #  FG  8  Inimage  ->  Out  Image, stgcode 

End  If  ;HexMode  or  connectivity  4  or  8 
EndProcedure  ;MarkTees 
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The  EPICAL  procedure  FindTees  is  coded  as  a  procedure  in  C4PL 
that  uses  arrays  to  set  up  a  stage  operation  that  finds  T-type 
intersections  of  pixels  in  a  certain  state  (and  assuming  a  certain 
connectivity).  The  code  presented  here  is  a  simplified  version  of  the 
procedure  as  it  exists  in  C4PL . 

FindTees  differs  from  MarkTees,  in  that  all  points  except  those 
that  meet  the  "tee"  criteria  are  changed  to  zero.  Marktees  only 
changes  the  state  of  pixels  that  meet  its  neighborhood  cri teri a--other 
pixels  are  unchanged. 
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Environmental  Easearcn 

Copyright  -  1990 


MACRO  NAME:  F;ndTees 

ABSTRACT:  Find  T-connect’ons  of  lines  in  state  'FGState1  assuming 

a  certain  connectivity. 

ENVIRONMENT:  C4PL  V2.5 

SPECIFICATION:  FindTees  FGState  OutState  Connectivity 

Inputlmage  ->  Outputlmage  StageCode 

States  0  througn  255  are  valid  input  parameters.  For  illegal 
values,  an  error  message  will  be  output  to  the  terminal. 

The  input  image  is  assumed  to  be  the  binary  image  of  a 
skeleton  in  'FGState'  in  rectangular  or  hexagonal  coordinates. 
The  output  image  is  a  binary  image  of  the  center  of  the  tees 

found  in  the  original  image,  in  OutState,  and  all  other 

pixels  are  zero. 

DESCRIPTION:  For  all  pixels  in  state  'FGState'  in  the  input  image,  look  for 

3  or  more  neighbors  in  state  'FGState'  in  the  configuration 
given  below.  Whenever  this  is  the  case,  change  the  center 
pixel's  state  to  ‘OutState’,  otherwise  change  it  to  zero. 

The  word  'configuration'  represents: 

N-E-S-W  if  'connectivity'  is  4 

N-NE-E-SE-S-SW-W-NW  if  'connectivity'  is  8  and  we're 

in  rectangular  mode 

N-NE-E-SE-S-W  if  'connectivity'  is  8  and  we're 

in  hexagonal  mode 

INPUT  PARAMS:  FGState:  foreground  state  default:  I 

-  find  tees  in  this  state) 

OutState:  output  state  default:  1 

-  mark  tees  found  by  changing 
them  to  this  state) 

Connectivity:  connectivity  default:  4 

-  4  ’  4-way  connectivity  assumed  for 

input  image 

-8s  8-way  connectivity  assumed  for 
input  image 

-  illegal  values  take  default 

Inputlmage:  input  image  default:  active 

OUTPUT  OATA:  Outputlmage:  output  image  default:  active 

StageCode:  stage  code  repository  default:  default 

(execute  it) 

EXTERNAL:  uses  other  C4Pt  ccmmands:  makearray,  arraytocode,  applycode 

I/O  &  FILES:  none 
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scnstants  used  in  program 

;  first  element  in  NRam  and  PRam  arrays 
;  'ast  element  in  Nram  and  PRam  arrays 
;  *here  high  NRAM  starts  relative  to  full  NRam 

;  number  of  bytes  in  stagecode  registers 
;  number  of  bytes  in  half  NRam 

;  define  valid  state  value  range 


;  test  control  bits  =  "00“  (Equal  Zero) 
;  test  control  bits  »  "01"  (Carry  Out) 


.  ,...**.•****••••••«*•*•«•**«*«»  set  defaults  for  the  arguments  here. 

setdef  1  ->  FGState 
setdef  1  ->  OutState 
setdef  4  ->  Connectivity 
setdef  active  ->  Inlmage 
setret  active  ->  Outlmage 


.  check  input  parameters. 

if  ((type  of (FGState)  o  TJJEFAULT)  8  (type_of (FGState)  o  T_INT) ) 

ERROR  "***  Foreground  state  must  be  an  integer." 
elseif  ((FGState  <  min_state)  |  (FGState  >  max_state)) 

ERROR  "***  Foreground  state  must  be  a  value~from  0  to  255." 
elseif  ((type_of (OutState)  o  T__0EFAULT)  &  (type_of (OutState)  o  T_INT) ) 

ERROR  "***_0utput  state  must-be  an  integer." 
elseif  ((OutState  <  min_state)  |  (OutState  >  max  state)) 

ERROR  "***  Output  state  must  be  a  value  from  5  to  255." 
endif 

if  ( (type_of (connectivity)  o  T_0EFAUIT)  8  (type_of (connecti vity)o  T_INT)) 
ERROR  “***  Connectivity  must”be  an  integer." 
elseif  ((type_of(connectivity)»T_INT)  &  (connecti vityo4)  &  (connectivityo8)) 
connectivity  :a  4 

printl  "***  FindTees  —  Warning:  Connectivity  has  been  changed  to  4." 
endi  f 


;  ***••••••••«*•*•••••*••**•***••  ^  dynamic  bias  is  on,  turn  off  temporarily 

if  OYNBIA 

printl  "***  FindTees  --  Warning:  Oynamic  bias  is  temporarily  being" 
printl  "  turned  OFF.  (for  FindTees  operation  only)." 

endif 


.  .*.**•*•.»**•••*•••**••*.«**.**  Tel  1  user  if  funny  bit  masks  are  used. 

if  ((INMASK  o  255)  |  (OUTMSK  <o  255)) 


syn  array_start  ’l" 

syn  array_end  '256" 

syn  NRam_offset  '255' 

syn  RegArraySize  "22" 

syn  NRamArraySize  '255' 

syn  min_state  “0* 

syn  max'state  "255" 

syn  equal_zero  "0" 

syn  carry  out  "2" 
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use.  ' 


determine  current  Hex  Mode  if  connective/ 
is  3.  Otherwise,  Hex  Mode  is  off  for  conn  =  4. 


;f  -‘EXMQQE 

if  (connectivity  =  3) 
hex_mode  16 

else 

hexjnode  0 

print!  '***  FindTees 
printl  " 
endif 
else 

hex_mode  : =  0 
endif 


;  *ant  Hex  Mode  to  stay  on  if  conn  =  3 
;  Pit  4  set 

;  connectivity  =  4,  so  Hex  Mode  's  off 
;  bit  4  off 

Warning:  Hex  Mode  is  temporarily  being" 
turned  OFF.  (for  FindTees  operation  only).' 

;  system  Hex  Mode  is  already  off 
;  bit  4  off 


.  .*»***»***»**»»**.**»***•**»**»*  create  the  arrays 

makearray  TJ3YTE,  RegArraySize  ->  control_reg 

makearray  T_BYTE,  NRamArraySize  ->  low__nram 

makearray  T_8YTE,  NRamArraySi ze  ->  high_nram 

.  »•••*****•*•**••••**»**«•*••*••  Make  a  bit  count  array,  first  time  only. 

;  »**•**••**•*••••*•*•****••••••*  if  array  exists  globally,  do  not 

;  .*,**.******«*•**•**«»»****«**.  execute  the  code.  (Hope  that  no  one  else 
.  , ,.«******•*****«****••**•**«•*  has  changed  the  values  someplace  else). 

if  (type_of(zw_bit_xarray)  o  t^array) 
makearray  T~byte,  NRamArraySize  ->  zw_bit_xarray 
for  cnt  array_start  NRamArraySize 

zw_bit_xarray[cnt]  :=  sum(cnt-l)  ;  count  of  bits  at  each  address 
endfor 
endif 


.  «.*.#«*»»*****»**•*««**********  assign  registers  in  control  array 

con t ro 1 _reg [mode _cont ro 1 ]  : 3  hexjnode | max _mode_of f | dyn_b i as_of f | out _cont ro 1 

control_reg[bias~value]  :*  0 

contro!”reg[output_mask]  :*  OUTMSK 

control _reg[input_ia$k]  •.*  INMASK 


****************************  5et  up  the  neighborhood  configuration  N-E-S-W; 
****************************  enable  the  others  if  connectivity  is  8.  Also 
»*•*••«*•••**•**••****•••**•  set  the  contribution  bits  in  the  same  manner. 


control _reg 
control _reg 
control~reg 
control ^neg 
control~reg 


[n_control 

e~control 

's^control 

^'control 

'^control 


disable_off 

disablejoff 

disable”off 

disable”off 

disable”off 


equal_zero 

equal^zero 

equal^zero 

equal^zero 

equal~zero 


control_reg 
control ~reg 
control'reg 


n_contrib 

Vcontrib 

's~contrib 


-  (  FGState  4  INMASK  ) 

-  (  FGState  4  INMASK  ) 

-  (  FGState  4  INMASK  ) 
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control  '•egi.w_C3ntr -3]  :»  -  rGState  J  INMASK  ) 
centra!  '•egLC_z:ntnt>j  -  rGState  i  INMASK  ) 

■  ''connectiv :ty  *  4} 

:ontrol_reg(ne_contro1 
control~reg[se_contror 
control~regfnw_control . 
control  _reg[sw_control' 

contral_reg[nej:ontrib]  :*  Q 

control~reg[sej:ontrib'  :=  0 

control_reg[nw~contrib'  : -  0 

control_regLswj:ontribj  :=  0 

elsaif  HEXMODE  ;  connectivity  *  8,  hexmode  *  on 

control  regfne  control]  :=  disab1e_off  equal_zero 

control~regfse~control '  :=  disable~off  equal~zero 

control_regfnw""control'  :=  disable_on  carry~out 

control~reg[swj:ontro!]  :*  disablejAn  |  carry~out 

control_reg[ne_contribl  :*  -  (  FGState  &  INMASK  ) 

contro1~regfse~contrib'  :=  -  (  FGState  &  INMASK  ) 

control_regfnw~contrib|  :*  0 

control _reg[svTcontrib]  :•  0 

else  ;  connectivity  *  8,  hexmode  *  off 

control_reg[ne_controll  :*  disable_off  equal_zero 

control_regfse~control'  :=  di$able~off  equal_zero 

control-reg[nwj;ontrol‘  •.*  disable_off  equal_zero 

control~reg[sw~controlJ  :*  disable_off  equal_zero 

control_reg[ne  contrib]  :=  -  (  FGState  &  INMASK  ) 

control~reg[se~contrib'  :=  -  (  FGState  &  INMASK  ) 

control~regfnw_contrib’  :=  -  (  FGState  &  INMASK  ) 

controPregLsvTcontribJ  :■  -  (  FGState  &  INMASK  ) 

end  if 


;  *****  Set  up  NRAM.  In  the  first  half  (low  portion)  of  the  NRam,  the  center 
;  *****  fails  the  test  so  we  want  to  output  a  zero.  In  the  second  half  (high 
;  *****  portion)  the  center  passes  the  test  so  we  want  to  count  the  neighbors. 
.  .***.  We  neeg  t0  see  3  or  more  neighbors  to  be  a  branch. 

low_nram[array_start  :  array _end]  :■  0 

high_nram[*]  :»  (zw_bit_xarray[*]>*3)*0utState 


;  *******************************  combine  the  arrays  to  form  stagecode 
arraytocode  low_nram,  high_nram,  control_reg  ->  .TempCode 


.  **••*••*•*••*••«•**•••«••••****  jjQ  tf,e  operation  or  store  the  code  generated 

if  (type  of (StgCode)  *  T_UNOEFINED)  ;was  stgcode  specified? 

applycode  TempCode  InTmage  ->  Qutlmage  ;no--execute  it 

elseif  (type  of(StgCode)  *  T  STAGECODE)  ;is  stgcode  stagecode? 

StgCode  :*  StgCode  *  TempCode  ;yes--append 

else 


;  connectivity  =  4 
disaole_on  i  carry_out 
3isable_on  I  carry_out 
disaole_on  |  carry_out 
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'empCode 


; n o  —  phis  is  first 


eraprocedure  ;  FindTees 


tageop 
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8.3  SKEL4 


The  S ke 1 4  routine  provides  an  example  of  utilizing  C4PL  commands 
to  generate  the  stagecode  desired,  then  tweeking  it  slightly  to 
produce  interesting  variations.  S ke 1 4  is  currently  an  unsupported 
routine  available  in  C4PL.  It  uses  the  same  Match  neighborhood 
specifications  as  the  SkelRec4  procedure  in  C4PL. 
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‘^ERIM 


Environmental  ^esearcrt  Institute  of  Micmgan 
Copyright  -  1989 


MACRO  NAME:  ske14 

ABSTRACT :  Rectangular  skeletonizing  operation  with  4-way  connectivity. 

ENVIRONMENT:  C4PL  V2.5 

SPECIFICATION:  skel4  ns  fg  flesh  passes  endpts  singpts  inimage  -> 

•  outimage,  stgcode 

Perform  a  skeletonizing  operation  that  maintains  4-way 
connectivity,  with  endpoint  and  single  point  reduction  as 
options.  A  'normal'  skel  changes  the  foreground  state 
to  flesh  state.  If  ns  (neighbor  state)  is  specified  then  a 
conditional  skel  is  performed,  where  the  foreground  is  only 
skeletonized  where  it  is  in  contact  with  the  ns.  If 
the  foreground  (fg)  is  not  specified  then  all  states  are 
skeletonized. 

Conditional  and  'all  states'  can  NOT  be  combined. 

DESCRIPTION:  Reduce  foreground  state  by  eating  away  from  four  successive 

directions  (E,S,W,N)  without  breaking  4-way  connectivity  of 
foreground  area.  Operation  must  be  applied  sequentially  in  tk 
four  directions  so  as  not  to  reduce  foreground  to  nothing  in 
one  stage. 


INPUT  PARAMS: 

ns: 

neighbor  state 

default:  default 

fg: 

pixel  state  to  skeletonize 

default:  I 

flesh: 

new  pixel  state 

default:  0 

passes: 

number  of  passes 

default:  I 

endpts: 

reduce  endpoints  flag 

default:  false 

singpts: 

eliminate  single  points  flag 

default:  false 

in image: 

input  image 

default:  active 

OUTPUT  OATA: 

outimage: 

output  image 

default:  active 

stgcode: 

stage  code  repository 

default:  default 

(execute  it) 

EXTERNAL: 

uses  other 

C4PL  commands:  match,  setdef,  setret,  rotate_code, 

I/O  &  FILES: 

type_of 

none 

:  HISTORY: 

Rev 

Date 

Author 

Description 

O 

J^Mar-89 

pak 

original  code  -  derived  from  Pascal 
external  task 

0.1 

6-Apr-89 

pak 

generalized  for  conditional  and  all  sts 

0.2 

15-May-89 

pak 

change  single  pt  neighborhood  to  produce 
results  of  Pascal  skelrec4  exactly 

0.3 

I3-Sep-89 

pak 

some  optimizations  for  speed 

0.4 

06-0ec-39 

pak 

changes  in  rotatecode->changes  here 
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3 rccedure  , ns , , 


esh, passes, enacts,  singpts , inimage)  ->  outimage.stgcode 


:?c'a re  tempnex,  4 

■index,  4 

skeiccde,  4 

skelcodei,  4 

skelcode2,  4 

stageop,  4 

stg_prefix,  4 

stg_suffix,  4 

east,  4 

tf 


temp  storage  for  hexmode  sys  variable 
loop  index 

whole  skeleton  stage  code 

first  pass  stage  code 

second  and  subsequent  passes  stage  code 

work  area  for  stageop  tweeks  for  cond.  skeis 

header  pram 

trail ing  pram 

test  value  for  match,  depends  on  conditional 
temporary  foreground  variable 


syns  fQr  CQntro1  registers 


syn 

mode_control 

'3" 

;1  +2  (we're  indexing  stageccde 

syn 

mode_dyn  bias 

”4" 

syn 

ne_contrib 

”16" 

:  14  +2 

syn 

e_contrib 

’17" 

;  15  +2 

syn 

cjcontrib 

”24" 

;  22  +2 

j  ***•*«»*•*■******•***•■*•**«•*•***•**•*  defaults 

;  no  default  for  ns  (if  it's  defaulted  then  we're  not  conditional) 

;  no  default  for  fg  (if  ft's  defaulted  then  we're  to  do  all  states) 
setdef  0  ->  flesh  ;  skeleton  flesh  state  is  0 

setdef  1  ->  passes  ;  one  pass  assumed 

setdef  false  ->  endpts  ;  do  not  reduce  end  points 

setdef  false  ->  singpts  ;  do  not  remove  single  points 

setdef  active  ->  inimage 
setret  active  ->  outimage 

I  parameter  checking 

if  ((type_of(ns)  o  T_INT)  S  (type  of(ns)  o  TJDEFAULT) ) 
print  1  "***skel4  —  Error:  neighbor  state  not  a  valid  type.'' 
return 

elseif  (type  of(ns)  »  T  INT) 
if  ((ns  <  5)  |  (ns  >  255)) 

print  1  "***skel4  —  Error:  neighbor  state  not  in  0-255  range." 
return 
endif 
endif 

if  ((type  of (fg)  o  T_INT)  4  (type_of(fgl  o  T  DEFAULT)) 
print  1  ‘***skel4  --  Error:  forground  not  a  valid  type." 
return 

elseif  (type  of(fg)  »  T  INT) 
if  ((fg  <  5)  |  (fg  >  255)) 

printl  “***skel4  —  Error:  forground  not  in  0-255  range." 
return 
endif 
endif 

if  ((type_of(ns)  o  TJEFAULT)  4  (type  of(fg)  -  T  DEFAULT)) 
printl  "***skel4  —  Error:  can't  do  a  conditional  skeleton  of  all  states.” 
return 
endif 
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■'  t, pe_of . esb )  o  T_:nT) 
pr-otl  '"'s<»U  --  Error:  *'’esh  not  an  -nteger.' 
'■“turn 

e’seif  'f’esn  <  0)  j  (flesn  >  255)) 
pr;r t!  *  * 's  ke 1 4  --  Error:  " esn  net  in  0-255  range.1 
'•eturn 
endi  f 

if  (type_of (passes)  o  T_INT) 
printl~'*,'’ske14  --  Error:  passes  not  an  integer.' 
return 

elseif  (passes  <  0) 

print!  "***skel4  --  Error:  passes  is  negative.' 
return 
endi  f 

if  (type_of (endpts)  o  T_B00LE4N) 
printl~"***skel4  --  Error:  endpts  flag  not  a  boolean." 
return 
endi  f 


if  (type_of (singpts)  o  T_800LE.4N) 
printl~"***skel4  --  Error:  singpts  flag  not  a  boolean." 
return 
endif 

temphex  :■  false 
if  hexmode 

printl  "Warning  -  skel4  temporarily  setting  hexmode  switch  off" 
temphex  :*  hexmode 
hexmode  :*  false 
endi  f 

•  »»*»***»•********•****■•»*•**•**  some  initializations 

empty  ->  stg_prefix  ;  makes  these  variables  into  stagecode 
empty  ->  stg_suffix 

.  ••••••«*•••••«*•••*••••*••**•»*  se^  temporary  foreground  variable  ' tf ’ 

if  (fgo#)  ;  tf  exists  because  of  all  states  option.  Normally  tf*fg 
tf  :*  fg 
else 

tf  :*  0  ;  could  be  anything  0-255  (should  avoid  dummy  states) 

endi  f 


handle  dummy  states  if  flesh  state  0 


;  and  set 

if  (nso#)  ;  if  conditional... 

;  we  always  use  1  dummy  for  conditional 
;  we  need  2  if  the  flesh  state  is  0 
if  (flesh  »  0) 

exch  0  0UWY2  ->  ,stg  prefix 
cover  0UMMY1  0UMMY2  ->  ,stg_suffix  ; 
exch  0  DUMMY2  ->  ,stg_suffix  ; 

if  (ns  *  0) 
ns  :=■  0UMMY2 
endi  f 


"east"  neighbor  for  match  cmds 


skeletonizing 


0UWY2  is  temporary  flesh  state 
DUMMY1  maps  to  (temp)  flesh  state 
dummy  states  go  to  specified  flesh 
state  (0)  when  all  done 

if  ns  also  0  it  must  be  remapped 
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zc^er  OUMMYl  flesh  ->  ,stg_suffix  ;  conditional  skels  need  one  -mused 

state  for  calculations 

-’eso  : =  I'.MMYl 

;  '•  n  conditional  skels  the  east  neighbor  is  special  test  case... 
east  :*  ns 
1  se 

;  not  conditional 
if  (flesh  =  0) 

exch  0  DUMMY 1  ->  ,stg_prefix  ;  a  zero  output  state  has  special 


stg_suff'ix  •-  «*g_pref’x 


a  zero  output  state  has  special 
meaning  in  NRAM--must  change  a 
flesh  state  of  0  to  something  else 
during  skel  processing... 
and  map  "something  else1'  back  to  0 
when  done 


flesh  DUMMY  1 

endi  f 

;  non-conditional  (and  not  all  states)  skels  -  the  east  neighbor  is  normal 
east  :=  "tf 
endif 


I*************************,** 


generate  skel  code  using  match  command 


;  eat  one  direction  at  a  time 

(else 

if  singpts 

match  flesh 

#  ~tf  ~tf  & 
"tf  tf  east  & 

"tf  ~tf  ~tf 

0  OR 

match  flesh 

#  ~tf  tf  4 
"tf  tf  east  & 

tf  ~tf  ~tf 

0  OR 

match  flesh 

tf  ~tf  ~tf  & 
"tf  tf  east  & 

tf  ~tf  ~tf 

0  OR 

match  flesh 

tf  ~tf  tf  4 
~tf  tf  east  & 

tf  ~tf  tf 

0  OR 

endif 

if  endpts 

match  flesh 

#  ~tf  #  & 
tf  tf  east  & 

#  "tf  # 

0  OR 

endif 

match  flesh 

tf  tf  #4 
tf  tf  east  4 

tf  tf  # 

0  OR 

match  flesh 

tf  tf  #4 
tf  tf  east  4 

#  "tf  # 

0  OR 

match  flesh 

#  "tf  #4 
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~f  tf  east  1 
t  f  tf  * 


->  .skelcodel 


t*eek  skelcodel  as  needed  for  /ariations 


•f  '.fg=») 
ske! codel 
s<elcodel 
endi  f 


;  all  state  skeletonizing... 


[1]  [mode_controI]  sxelcodel [1] [mod 
[ 1 j [ne_Contrib:c_contrib]  :s  0 


e_controi]  J  mode_dyn_bi as 


now  generate  and  append  stageops  for 
other  3  directions 


rotatecode  skelcodel  90  hexmode  ->  .skelcodel 
rotatecode  skelcodel  180  hexmode  ->  .skelcodel 
rotatecode  skelcodel  270  hexmode  ->  .skelcodel 


skelcode2  :=■  skelcodel 
if  (  (passes>l)  &  (nso#) 


generate  2nd  and  subsequent  passes  stagecode 

Multiple  passes  use  same  code  except 
in  conditional  skeletons: 
addl  passes  need  flesh  state  in  the 
east  neighbor  contribution  value. 


stageop  :«  skelcodel[l]  ;  Extract  stageop  from  stagecode--must  do  it 

stageop[e  contrib]  :»  -flesh  ;  this  way  to  generate  a  copy  of  the  stage  op 
skelcode2tl]  •:*  stageop  ;  to  modify  and  use  in  place  of  original, 

rotatecode  skelcode2  90  hexmode  ->  ,skelcode2 
rotatecode  skelcode2  ldQ  hexmode  ->  ,skelcode2 
rotatecode  skelcode2  270  hexmode  ->  ,skelcode2 
endif 

;  *******************************  multiply  by  number  of  passes  and  add  prams 
skelcode  :■  stg_prefix  +  skelcodel  +  skelcod<*2  *  (passes-1)  +  stg_suffix 


******************************* 


do  the  operation  or  store  the  code  generated 


if  (type_of (stgcode)  »  T_UNDEHN£D) 
applycode  skelcode  inimage  ->  outimage 
elseif  (type_of (stgcode)  *  f_STAGE€00E) 
stgcode  :»~stgcode  ♦  skelcode 

else 

stgcode  :*  skelcode 
endif 


was  stgcode  specified? 
no--execute  it 
is  stgcode  stagecode? 
yes --append 

no--make  stgcode*skelcode 


**  *★♦■*♦■#****♦*****■**■•'*****■***** 


reset  hexmode 


hexmode  :*  temphex 


we're  done!  (with  skel4) 


endprocedure 
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